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PREFACE 



The Network Operating. System (NOS) was developed by Control Data 
Corporation to provide network capabilities for time-sharing and 
transaction processing, , in addition to local and remote batch 
processing, on CONTROL DATA CYBER 170 Series Computer Systems; 
CDC CYBER 70 Series, Models 71, 72, 73, 'and '74 Computer Systems; 
and CDC 6000 Series Computer Systems. 

AUDIENCE 

This internal maintenance specification (IMS) provides the 
systems analyst with detailed internal documentation of NOS. 
Included are detailed descriptions of system routines and the 
system interfaces, tables, and flowcharts of these routines. 
Some user interfaces are mentioned, but these are fully described 
in other NOS manuals. 

CONVENTIONS . 



Extended memory for the CYBER 170 Models 171, ''72, 173, 174, 175, 
720, 73 0, 750, and 7 60 is extended core storage (ECS). Extended 
memory for CYBER 170 Model 176 is large central menory (LCM) or 
large central memory extended (LCME). ECS and LCM/. C ME are 
functionally equivalent, except as follows: 



•LCM/LCME cannot .link mainframes and does not 
distributive data path (DDP)cap ability. 



have a 



• LCM/LCME transfer errors initiate an error exit, not a 
half exit. Refer to the COMPASS Reference Manual for 
complete information. 

The Model 176 supports direct LCM/I.CME ti^:^,- COMPASS 
instructions (octal codes 014 and 015). Refer to the COMPASS 
Reference Manual for complete ; inf ormation. 

In this manual the acronym ECS refers to all forms of extended 
memory on the CYBER 170 Series, However, in the context of a 
m u 1 1 i mainframe environment or DDP access, the Model 176 is 
excluded. 

In this manual, the order of importance of headings is denoted as 
follows. 

LEVEL 1 HEADINGS'" A'RE' FULL CAPS AMD UNDERLINE D 

LEVEL 2 HEADINGS ARE FULL CAPS 

Level 3 Headings are First-Capped and Underlined 

Level 4 Headings are First-Capped 

Conventions for central memory word formats are as follows: 
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• Cross-hatching indicates a field is not used by or is 
not applicable to a function processor. However, CDC 
reserves the right to assign these fields to system use 
in the future. 

• Fields reserved for system use are so labeled. 

• Fields labeled with mnemonics indicate a specific 
parameter must be inserted (generally described after 
the word format) . 

• Fields with numeric identifiers indicate the actual 
value that is used or returned for a particular function 

RELATED PUBLICATIONS 

For further information concerning CYBER 170, CYBER 70, and 6000 
Series Computer Systems, the NOS time- sharing systems, and the 
user interface for NOS, consult the following manuals. 



Control Data Publication Publication No. 

CYBER 170 Computer Systems Reference Manual 60420000 

CYBER 170 Computer Systems 60456100 

Models 720, 730, 750, and 760 
Model 176 (Level B) 

CYBER 70/Model 71 Computer System Reference 60453300 
Manua I 

CYBER 70/Model 72 Computer System Reference 60347000 
Manua I 

CYBER 70/Model 73 Computer System Reference 60347200 

Manual 

CYBER 70/Model 74 Computer System Reference 60347400 

Manua I 

Modify Reference Manual 60450100 

Network Product s 

Interactive Facility Version 1 Reference Manual 60455250 

Network Products 

Transaction Facility Version 1 Reference Manual 60455340 

Network Product s 

Transaction Facility Version 1 User's Guide 604553 60 

Network Product s 

Transaction Facility Version 1 

Data Manager Reference Manual 60455350 
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IV 



Control Data Publication 



Pub I i cat ion No . 



Network Products 

Transaction Facility Version 1 

CYBER Record Manage r 

Data Manager Reference Manual 

Network P roduc t s 

Network Access Method Version 1 Reference. Manual 

Network Products 

Network Access Method Version 1 

Internal Maintenance Specification 

Network Products 

Remote Batch Facility Version 1 Reference Manual 

NOS Version 1 -'Ins tal. la t ipn . Handbook 



NOS Versi 
NOS Versi 
NOS Vers 
NOS Vers 
NOS Vers 
NOS Vers 



on 1 Operator's Guide 

on 1 Reference Manual Volume 1 

on 1 Reference Manual Volume 2 

on 1 System Maintenance Reference Manual 

on 1 System Programmer's Instant 



60456710 
60499500 

60490110 

60499600 
60435700 
60435600 
60435400 
60445300 
6045538Q 
60449200 



on 1 Time-Sharing User's Reference Manual 60435500 



NOS Version 1 Expo rt / Import Reference Manual 

TAF/TS Version 1 Reference Manual 

TAF/TS Version 1 User's Guide 

TAF/TS Version 1 Data Manager Reference Manual 

TAF/TS Ver ion 1 CYBER Record Manager 
Data Manager Reference Manual 

6400/6500/6600 Computer System Reference 
Manua I 

DISCLAIMER 



60436200 
604530Q0 
60436500 
60453100 
60456700 

60100000 



This product is intended for use only as described 
in this document. Control Data cannot be responsible 
for the proper functioning of undes c r i bed features or 
undefined parameters. 
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10 



Control point management enables the user to alter or interrogate 
parameters in the job's control point area. Control point 
management consists of a set of control statements, macros, and 
the PP routine control point manager (CPM). 

CPM is called as follows: 

• A user can issue an RA + 1 call to CPM or the appropriate 
macro which generates an RA*+1 call. 

• A user can use the appropriate control statement, which 
causes CPU program CONTROL to be loaded in the user's 
field length. CONTROL then uses the appropriate macro to 
generate the RA+1 call to CPM. 

The macro definitions for CPM functions are found in SYSTEXT 
(and NOSTEXT), PSSTEXT, or in common decks COMCCMD and COMCMAC. 
Those defined in SYSTEXT are general use macros, such as EREXIT 
and USERNUM, while those macros defined in PSSTEXT and COMCCMD 
and COMCMAC have special system usage, such as MODE, GETJA, and 
SETUI. All CPM macros require common decks COMCCPM and COMCSYS. 
A detailed description of each user CPM function and its macro 
call is available in the NOS Reference Manual, volume 2. 

The PP routine CPM performs the requested CPM function except 
for those CPM functions that are performed by CPUMTR because of 
their high usage. The functions are outlined in table 10-1. 
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10-1 



TABLE 10-1. CPM FUNCTIONS 



Code 



Desc ri pt i on 



CPM 
Overlay 



CPM 
Ent ry 
Point 




1 
2 
3 
4 
5 
6 
7 

10 

11 

12 

13 

14 

15 

16* 

17 

20 
21 
22 
23 
24* 



Set queue priority 

Set CPU priority 

Set exit mode 

Set time and SRU Limit 

Set error exit return address 

Set K-display register 

Ro I Lout j ob 

Set no exit/on exit bit 

Set secure system memory 
Turn on sense switches 
Turn off sense switches 
Read job name 
Read queue priority 
Read CPU priority 
Read exit mode 
Ret ri eve Limit 

Enter demand index 
Set user i ndex 
Set Loader control word 
Set Last RFL (CM/ECS) 
Read job control word 



CPM 
CPM 
CPM 
3CB 
3CC 
CPM 
CPM 
CPM 

CPM 
CPM 
CPM 
CPM 
CPM 
CPM 
CPM 
3CB 

CPM 
3CA 
CPM 
CPM 
CPM 



SQP 
SPR 
SEM 
SLL 
SEE 
SDA 
ROC 
NEX 

SSM 

ONS 

OFS 

RJN 

RQP 

RPR 

PRS1 

RLM 

EDI 
SUI 
SLC 
RFL 
PRS1 



* Processed by CPUMTR 
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TABLE 10-1. CPM FUNCTIONS (CONTINUED) 



Code 



Descri pt ion 



CPM 
Ove r lay 



CPM 
nt ry 
oi nt 



25* 

26 

27 

30 

31 

32* 

33* 

34 

35 

36 

37* 

40 

41 

42 

43* 

44 

45* 

46 

47 

50* 



Set job control word 

Set subsystem flag 

Read job origin code 

Read accounting information I 

Select CPU to execute in ! 

Return user number 

Read FL contro I word 

Enter event into system event table 

Set pack name 

Return pack name 

Set subsystem flag 

Validate user number 
Enter f ami ly name 
Special charge functions 
Disable SSJ= control 
Return version name 
Get loader control word 
Get global library set 
Set globaL library set 

Return machine ID 



CPM 

CPM 

CPM 

3CB 

CPM 

CPM 

CPM 

CPM 

CPM 

CPM 

CPM 
I 
I 
| 3CA 

| 3CA 

I 

| 3CB 

I 

| CPM 

I 

| CPM 

I 

| CPM 

I 

| 3CC 

I : 

| 3CC 

I 
I 
I CPM 



PRS1 

SSF 

ROT 

RAI 

SCP 

PRS1 

PRS1 

EET 

SPN 

RPN 

PRS1 

VAN 

FAM 

SCF 

PRS1 

RVN 

PRS1 

GLS 

SLS 

PRS1 



* Processed by CPUMTR 
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TABLE 10-1. CPM FUNCTIONS (CONTINUED) 



Code 



Desc ri pt ion 



CPM 
Overlay 



CPM 
Ent ry 
Poi nt 



51 

52 

53 

54 

55* 

56 

57 

60 

61* 

62* 

63-72 

73 

74 

75 

76 



Return job activity information 

Set maximum field length .(CM/ECS) 

Toggle SRU calculation 

Set job class 

Read ECS Control word 

Validate user 

Get permanent file parameters from 
control point area 

Set permanent file parameters in 
control point area 

Get list of files address 

Set list of files address 

Reserved for CPUMTR 

Decrement family user count 

Job control information 

Set/ clear job control flags 

Set/clear override required to drop 
job flag 



CPM 
CPM 
3CB 
CPM 
CPM 
3CA 
CPM 

3CA 

CPM 
CPM 
CPM 
3CA 
CPM 
CPM 
CPM 



RAC 

MFL 

CSC 

SJC 

PRS1 

VAL 

GPF 

SPF 

CXA1 

CKA1 

PRS1 

DFC 

J CI 

PRO 

SOV 



* Processed by CPUMTR 
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The format of the RA+1 call to CPM is as follows: 

59 40 23 _0 

y\ j | ~~ 

RA+1 



CPM 


/ 
/ 
/ 
/ 


r 


code 


param 



r Autorecall bit 

code CPM function code 
parameter Parameter for the function 
FUNCTION PROCESSING 



CPUMTR checks in the table of CPM function codes for those 
function codes that are processed in CPUMTR. The remainder of the 
CPM functions are processed in PP routine CPM. CPM consists of a 
preset routine (PRS) and processors for the individual functions. 
Preset performs function code and special parameters verification 
and calls the appropriate function processor. Although the CPM 
functions processed by CPUMTR are defined in CPM's function 
table, they are all processed as errors if those function codes 
were recognized by .CPM. 

CPM ORGANIZATION 

CPM consists of the main program (CPM) and the processors and 
subroutines listed in table 10-1. 

The following subroutines are used by CPM. 



Subroutine 
and Ove r lay 

CFN/CPM 

DSC/3CA 

CKA/CPM 

CUF/3CB 

LBD/3CC 

PMP/CPM 

RLN/3CC 

RLW/3CC 

R U I / 3 C A 

SPP/3C8 



Desc ri pt i on 
Compare family names 
Decrement security count 
Check address 

Check for profile file update failure 
Search library directory for special entry 
Process memory parameters 
Return Library name to user program 
Read library name from user program 
Read user identification word 
Set profile parameters 



60454300 A 



10-5 



Sub rout i ne 
and Ove r Lay 

UFC/CPM 

UPF/3CB 

ERR/CPM 



Desc ri pt ion 

Update family activity counts 

Update project profile file using overlay 
OAU 

Process error 



The following common decks are used by CPM. 



Common Deck/Overlay 
C0MPECX/3CA 
C0MPCMX/3CA 
C0MPSFE/3CA 
COMPCVI/CPM 
C0MPCRA/3CB 
C0MPGTN/3CB 
C0MPFAT/3CB 
COMPRJC/CPM 
C0MPSTA/3CB 
COMPVFN/CPM 



Pes c ri pt i on 
Compute ECS maximum field length 
Compute maximum field length 
Set family equipment 
Convert validation indexes 
Convert random address 
Generate terminal number 
Search for fast-attach file 
Read job control word 
Set terminal table address 
Verify file name 



CPM organization is completed by the preset routine (PRS), the 
function table (TFCN), and common deck COMPCRS (check recall 
st atus) . 
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LOCAL FILES 



11 



A file is a collection of data saved on a storage . medium. . It 
can be tape or mass storage. The data is written in groups of 
blocks or sectors. The system controls and designates a file by 
its FNT and keeps its position by the FST. 

There are basically two kinds of files. 

• Explicit files are defined by an FNT/FST. 

• Implicit files are known only by a track reservation in 
the TRT. They are actually track chains and, as such, 
are managed by the owner. They are, more specifically, 
files unknown to the system. The best example of this 
type of file is the indirect permanent file track 

ch a in . 



This section describes those files 
exp I ici t ly ..... 



known to the system 



The FST is used basically 



These files all have an FNT/FST entry. 

for file positioning information, with exceptions for queue type 

files. Refer to Section 2 for formats of FNT/FST entries. 

The FNT/FST is created for several reasons. With the exception 
of 1TA for TELEX rollout files, all files are created (that is, 
an FNT/FST entry is built) by the PP routine OBF (begin file). 
With no exceptions, FNT/FST entries are cleared (that is, the 
files are dropped) by the PP routine ODF (drop files). 
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d e t e 
FNT/ FS 



t y i f t 
found a 
h any I 
rs. On 
i I e wit 
must re 
that a 
finds 
ed, i t 
t were 
i ng, or 
tine to 
rm i nes 
T ent ry 



he lfn=0. When a new file 
nd used for this new file, 
ocal file name, even those 
ly a PP routine can use OBF, 
h any 1- to- 7 -character 
quest CIO to create a file 
name be composed of 1 to 7 

a special character in a 
aborts the program, 
previously created with an 
positioning. This allows 
use the file DM*, which is 
that the Ifn is legal, it 



The job origin field always contains the origin code of the 
creator of the file ( S Y0T = 0, BC0T = 1 , for example). 

Bit 5 of the FNT is set for mass storage files whose system 
sector contains information for later processing ( for example, 
input and output queue files). 
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The control point number field of the FNT contains the control 
point number of the current user of the file. 

The file type field defines what type of file it is. If the 
control point number is zero, then the file is not assigned to a 
control point; this is usually the case for files in a queue. 
This field is set up by OBF in the following manner. A table of 
file names is kept in OBF's FL. The file type is set to the 
corresponding file name. If the caller of OBF desires that the 
file have a file type different than OBF generates, the caller 
must change it himself. PFM changes the type to LOFT for the 
GET command, even if the name was one of those in the OBF table, 
and changes type to PMFT for ATTACH commands. 

The table is at location TSFN in OBF and contains the following. 



File Name 
INPUT 
OUTPUT 
PUNCH 
PUNCHB 
P8 
LGO 
Any ot he r name 



File Type 
LOFT 
PRFT 
PHFT 
PHFT 
PHFT 
LOFT 
LOFT 



FILE TYPES 

The following file types are defined by NOS 

The queue file types are as follows: 



Type 
INFT 
ROFT 
PRFT 
PHFT 
TEFT 



Va lue 

1 
2 
3 
4 



Description 
Input 
Ro I lout 
Print 
Punch 
Ti med/ event ro I lout 
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Special queue file types are as follows: 

Ty p e value Desc ript ion 

S1 FT 5 Speci al file type 1 

S2FT 6 Special file type 2 

S3 FT 7 Special file type 3 

Other file types include the following. 

Type Value Description 

Library 

Primary terminal 

Direct access permanent file 

Fas t attach file 



LIFT 


10 


PTFT 


11 


PMFT 


12 


FAFT 


13 



SYFT 



LOFT 



14 



15 



System 



Loca I 



File types INFT, ROFT, PRFT, PHFT, and TEFT are described in 
S ect i ons 5 and 6. 

Types S1FT, S2FT, and S3FT are special queue files that are 

reserved for use by NOS. 

Library files (LIFT) are locked common files that are currently 
assigned to a control point. An FNT/FST entry for a file of 
type LIFT always has a control point assignment. The library 
file type is also used by system utilities while dumping and 
loading queues, dayfiles, and permanent files. 

Primary files (PTFT) are created with the OLD or PRIMARY control 
statements. When the user issues the OLD command, a copy of the 
indirect access permanent file is created with PTFT type in 
unlocked mode. The NEW command creates a scratch file with type 
PTFT in unlocked mode. The PRIMARY command can be used to 
change a file of type LOFT to that of PTFT. 

The time-sharing user can additionally create a primary file 
with the LIBRARY command. The LIBRARY command requests a copy 
of an indirect access file from the user number LIBRARY (user 
index 377776B). It is equivalent to the following command. 

OLD, lfn=pfn/UN=LIBRARY. 
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When the user issues an ATTACH command, he gets the file pointed 
to by an FNT of type PMFT. If the file is attached in read mode, 
then many users can each get an FNT of type PMFT pointing to the 
same file. If a user attaches the file in write mode, it will 
be the only FNT pointing to the file. The DEFINE command is 
used to create a PMFT type file. 

Fast attach files (FAFT) are files which have an FNT always in 
the FNT table. PFM searches the FNTs first on an ATTACH command, 
and if it finds it there, PFM gives the user his own FNT/FST 
entry for the file and this entry has file type PMFT. 

System type files are files which are used by the system for 
special functions. Examples of SYFT files are VALIDUs, RSXDid, 
and RSXVid, which are created by the deadstart procedures and 
permanently remain at FNT ordinals 1, 3, and 4, respectively. 
These file types are changed to FAFT whenever ISF is run. If 
the ISF(R=lfn) is used, then the Ifn specified, if of type FAFT, 
is changed to type SYFT. 

Local type files (LOFT) are generally scratch files. They 
include any file created locally at a control point and any copy 
of an indirect access file created by the GET command. These 
files are automatically released by 1CJ at job completion time. 
Tape files are also considered local files. 



NOS supports common files (CMFT) only in 
user wants the use of this type of file, 
command after locking a local file 
creates a new FNT/FST for the user 
in read-only mode. Many users can 
each with his own FNT/FST pointing 



locked mode. When a 
he issues the COMMON 
LFM finds the FNT and 
of type LIFT. This file is 
read this file simultaneously, 
to the same file. The user 
must be validated to access library files (bit CASF set in AACW) . 

Locked common files are CMFT files with the write lockout bit 
(bit 12) set in the FNT. The bit is set by the LOCK command 
and unset by the UNLOCK command. However, when the creator of 
the file returns it or terminates, and if the write lockout bit 
is set, then the file can never be unlocked or released, except 
by a level-zero deadstart, or with the console memory entry 
commands. It is not possible to create an unlocked common file. 
The local LIFT FNT/FST is released at return or end-of-job time, 
but the CMFT entry remains in the FNT and the file space is not 
d ropped . 



60454300 A 



11-4 



LOCAL FILE MANAGER 

Local file management consists of a set of macros, control 
statements, and the PP routine LFM. LFM can be called with the 
following. 

• An RA + 1 call to LFM. 

• A macro which generates an RA+1 call to LFM. 

• A control statement which causes either RESEX or FILES 
to be loaded in the user's FL. RESEX is loaded for the 
ASSIGN, LABEL, and REQUEST control statements (refer to 
Section 12 for the discussion of tape assignment). 
Local mass storage file assignment uses the same 
procedure as tape assignment. FILES issues the 
appropriate macro (RENAME, COMMON, or RELEASE, for 
example) to generate an RA+1 call to LFM. 

When called to a control point, LFM locates or creates the 
FNT/FST for the desired file. It makes the appropriate changes 
in the FNT/FST entry for the function specified in the call. LFM 
also interfaces to RESEX if necessary. 

The routine FILES also does file skipping, rewinding, and WRITER 
and WRITEF commands. It calls CIO for these tasks. 

The macro definitions for LFM functions are found in SYSTEXT 
(and NOSTEXT) or in common deck COMCMAC or COMCCMD. Those macros 
defined in SYSTEXT are general use macros, such as RENAME, 
STATUS, and LABEL, while those macros defined in COMCMAC and 
COMCCMD have special usage, such as the ACCSF, ENCSF, and PSCSF 
macros used by the control language. All LFM macros require 
common decks COMCLFM and COMCSYS. A detailed description of each 
LFM function and its macro call is available in the NOS Reference 
Manua I , vo lume 2 . 

The PP program LFM consists of a group of overlays that performs 
the requested function. The functions and their corresponding 
LFM overlays are outlined in table 11-1. 



60454300 A 



11-5 



TABLE 1 1-1 . LFM OVERLAYS 



Code 



Fun ct i on 

Rename file 

Assign common file 

Enter common file 

Re Lease print file 

Release 026 punch file 

Release PUNCHB f i le 

Re lease P8 file 

Lock f i le 

Unlock f i le 

Return file status 

Return current position 

Request equipment 

Assign equipment 

Release files 

Set file ID code 

Access library file 

Attach control statement 
f i le 

Enter control statement 
f i le 

Position control statement 
file 

LABEL request 

Get all local FNTs 



Ove r lay 
LFM 
3LD 
3LD 
3LE 
3LE 
3LE 
3LE 
3LB 
3LB 
3LB 
3LB 
LFM 
3LC 
3LE 
3LE 
LFM 
3LF 

3LF 

3LF 

LFM 
3LG 



Entry Point 
RNI 
ACF 
ECF 
RPR 
RPH 
RPB 
RP8 
LCK 
ULK 
RLS 
RCP 
RQI 
AEQ 
REL 
SID 
ALF 
ACS 

ECS 

PCS 

LBI 
GTF 





1 

2 

4 

5 

6 

7 
10 
11 
12 
13 
14 
15 
16 
17 
20 
21 

22 

23 

24 
25 
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TABLE 11-1. LFM OVERLAYS (Continued) 




Function 



I Overlay 


Ent ry Point | 


I 3LC 


QAE I 


I 3LC 


VSN | 


| 3LE 


RPN I 


| 3LG 


PR I I 


I 3LB 


RFI | 



Request ope rator 
assignment of equipment 

Ent e r VSN ent ry file 

Release 029 punch file 

Make file primary 

Return file information 
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An outline of the LFM memory map is as 
represents LFM code prior to Loading a 
overlays are loaded at location OVL. 



follows. The map 
3Lx ove r lay . All 



3Lx 



PPFW 



OVL 



7777 



LFM- main program 



Resident subroutines 



Resident common decks 



Preset routine 

and other subroutines 

that may be overlayed 



Resident processors 



The RA + 1 call for LFM has the following format 

59 40 35 23 17 

RA + 1 



LFM 



/ 



code 



fp 



addr 



code 
fp 



addr 



Function code 

Function parameter (used by SETID function 

17, STATUS function 13, and equipment 

request function 26) 

Address of t he FET 



The main program (LFM) calls the preset subroutine (PRS) and 
then jumps to the appropriate subroutine to process the 
requested function (a 3Lx overlay is loaded, if required). LFM 
also contains the common return point, LFMX, for all function 
processors. LFMX sets the file status not busy, completes the 
FET status, and drops the PP. 
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The resident subroutines are called from the various function 
processors and include the following subroutines. 



Sub rout i ne 



Description 
Check error processing (bit 44 of FET+1 ) 
Compute parameter address 
Drop (release) equipment 
Drop file (calls ODF) 

Enter new file name in FNT (calls OBF) 
Abort job 

Process error (calls 3LA) 
Recall LFM 
Set file status 
Seach for and interlock file 
Set/clear pause bit 
Search for VSN entry file 
Resident common decks include the following. 

• COMPSAF Search for assigned file 

• COMPSEI Search for end-of - i nf o rma t i on 

• COMPSFB Set f i le busy 

• COMPSRA Set random address 

• COMPVFN Verify file name 

PRS checks the input register for a valid call to LFM, 
determines what overlay is needed to process the requested 
function, initializes some memory cells, and returns to LFM. 
Other subroutines, besides PRS, that are overlayed include thi 
following. 



CKE 


CPA 


DEQ 


DRF 


EFN 


ABT 


ERR 


RCL 


SFS 


SIS 


SPB 


SVF 



CRX 

TFCN 



Determine if RESEX has been called. 

Function table. Specifies the entry 
point address of the routine to 
process the requested function, and 
in which overlay that entry point is 
def i ned . 
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Resident processing routines are those routines not requiring 
the loading of a special 3Lx overlay or requiring special 
processng before loadng a 3Lx overlay. They are resident in LFM 
due to high volume use or special initialization processing. They 
include the following. 



ALF 



RNI 



Access library file (function 20) 



Rename (function 0) 



• RQI Request equipment (function 14) 

• LBI LABEL request (function 24) 

Also part of the resident processing routines are common deck 
COMPCRS (check recall status) and subroutine CRF (create 
relocatable routine FNT) and SSD (set system devices). The 
resident processing routines are also overlaid by 3Lx overlays 

LFM OVERLAYS 



The following paragraphs describe the LFM overlays. 

3LA - ERROR PROCESSOR 

Overlay 3LA contains the code and messages for error processing. 



3LB - LOCAL FILE FUNCTIONS 

Overlay 3LB contains the rename (0), lock (10), unlock (11), 
return last status (12), return current position (13), and 
return file information (32) functions. The routines in 3LB are 

as follows: 



Desc ri pt i on 
Rename file 
Lock file 
Un lock file 
Return last status 
Return current position 
Transfer UDT words 
Return file information 
Seach FNT for assigned file 



Rout i ne 


RNM 


LCK 


ULK 


RLS 


RCP 


TUW 


RFI 


SFN 
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3LC - EQUIPMENT REQUESTS 

Overlay 3LC contains those functions used in assigning an 
equipment to a given file. These functions are request 
equipment (14), assign. equipment (15),. label tape request (24), 
request operator assignment of equipment (26), and build tape 
file FNT/FST (27). The routines in 3LC are as follows: 



Description 

Request. equipment 

Assign equipment 

Label tape request 

Request operator assignment of equipment 

Bui Id tape f i le FNT/FST 

Assign nontape file 

Check equipment number 

Find tape equipment 

Request equipment assignment 

Request operator assignment 

Search for equipment 

Validate assigned equipment 

Validate SSJ= 

Validate system origin privileges 

Verify tape entry 

Common decks COMPACS (assemble character string) and C0MPC2D 
(convert 2 octal digits to display code) are also used in 3LC. 



Rout i ne 


REQ 


AEQ 


LBR 


OAE 


VSN 


ASF 


CEN 


FTE 


REA 


ROA 


SEQ 


VAE 


VSJ 


VSO 


VTE 
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3LD - COMMON FILE FUNCTIONS 

Overlay 3LD contains the assign common file to job (1) and enter 
common file (2) functions. The routines in 3LD are as follows: 



Routin e 
ACF 
EC F 



Description 
Assign common file to job 
Enter c ommon file 



SCF Search for common file 
USS Update system sector 
Common deck COMPWSS (write system sector) is also used in 3LD. 

3LE - FILE DISPOSAL FUNCTIONS 

Overlay 3LE contains those functions related to disposing a 
local file to an output queue. These functions are release file 
to print queue (4), release file to 026 punch queue (5), release 
file to binary punch queue (6), release file to 80~column binary 
punch queue (7), release file to 029 punch queue (30), release 
file to corresponding queue (16), and set file ID code (17). 
The routines in 3LE are as follows: 



Routine 


RPR 


RPH 


RPB 


RPS 


RPN 


REL 


SID 


ROF 


COL 


COT 


ISB 



Description 
Release file to PRINT queue 
Release file to 026 PUNCH queue 
Release file to PUNCHB queue 
Release file to P8 queue 
Release file to 029 PUNCH queue 
Release file to corresponding queue 
Set file ID code 
Release output fiLe 
Check output file limit 
C h ange origin type 
Initialize system sector buffer 
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Overlay 3LE contains the following common decks. 



Common Deck 
C0MPC2D 

CQMPRSS 
COMPCUN 
COMPCVI 
COMPSSE 
COMPUSS 

COMPWSS 
C M P R J C 



Descript ion 

Convert two octal digits to display 
code 

Read system sector 

Compare user numbers 

Convert validation indexes 

System sector error processor 

Update system sector for disposable 
files 

Write system sector 

Read job control word 



3LF - CONTROL STATEMENT F ILE FUNCTIONS 

Overlay 3LF contains the functions used to manipulate the 
control statement record by the job control language. These 
functions are attach control statement file (21), replace 
control statement file (22), and position control statement file 
(23). The routines in 3LF are as follows: 



Routine 
ACS 

ECS 
PCS 
PCF 



Description 

Attach control statement file under 
name from FET 

Replace control statement file 

Position control statement file 

Position control statement file 



Common decks COMPCRA (convert random address) and CQMPRNS (read 
next sector) are included i n 3 L F . 
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3LG - GETFNT AND PRIMARY FUNCTIONS 

Overlay 3LG contains the GETFNT (25) and PRIMARY (31) functions. 
The routines in 3LG are as follows: 



Routine 
GTF 

PRI 
CCP 

C FS 
MFF 
PCF 



Description 

Return table with FNT/FST entries for 
all working files 

Process primary function 

Crack calling parameters in FET and 
CGNT 

Check file selectivity 

Modi f y file's FST 

Process checkpoint file 



Overlay 3LG contains the following common decks 
Common Deck Description 



COMPWEI 
COMPWSS 



Write EOI sector 
Write system sector 
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RESOURCE CONTROL 



n 



Resource control involves the allocation of the system magnetic 
tape and removable pack resources. The control of these 
resources is handled by the NOS resource executive (RES EX). 

RESEX manages the assignment of magnetic tape and removable pack 
resources to user jobs without causing a deadlock to occur for 
those resources , 

This section describes the concept of resource overcommitment 
and the scheduling (assigning) of resource units by RESEX. 



OVERCOMMITMENT 

A portion of RESEX deals with managing the use of tape unitsand 
disk packs in such a way as to prevent deadlocks from occurring. 
The whole process is generally referred to as overcommitment, 
although the overcommitment of tape and disk resources is just a 

part of it. 

Before continuing the discussion of overcommitment, the 
following definitions are necessary. 

• A deadlock or potential deadlock condition exists when 
two or more jobs demand tape and pack resources such 
that no more resources are available (deadlock), or 
there are not enough free resource units available to 
satisfy the resource requirements of any of these jobs 
(potential deadlock). 

• An internal conflict condition exists if a job's 
current tape request or increased resource demands 
would deadlock the job itself. This can occur only 
when using PE resources (1600 cpi, 9-track tapes). 

• The resource demand for a job is the number of resource 
units that the job requires concurrently. This demand 
may be for a single resource type (for example, 7-track 
tape) or a combination 
and 9-track tape and a 



of resources (for example, 7* 
D-I-2) . 



Demand count and assigned count indicate the number of 
resource units required (resource demand) and the 
number of resource units assigned to the job 
respectively. 

The demand file is a fast attach permanent file 
manipulated by RESEX and its associated program (for ■ 
example, QRF) which contains the assigned and demand 
information for each job using tape and pack resources 
The entry in this file for a job is called the demand 
file entry. 

A resource unit is any magnetic tape or removable pack 
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The overcommitment algorithm is a subroutine in RESEX 
that processes demand file entries and determines 
whether jobs can be completed based on current resource 
usage. It also refers to the process of presetting 
tables that are used during the execution of the 
algorithm. 

The resource environment consists of all magnetic tape 
and removable disk drives currently defined in the 
system and the status of the tape or pack mounted on 
these drives. The environment is rarely static, as the 
assignment, mounting/dismounting, and status of the 
drives change during normal system operation. RESEX 
builds two working tables, the resource equipment table 
(RET) and the environment VSN buffer (EVSB), from 
information contained in the EST, MST, and MAGNET unit 
descriptor tables (UDT) . 

The share table provides RESEX with the information 
concerning which job is using which removable device. 
The active user count for a removable pack found in the 
MST tells only how many direct access files are being 
accessed, but does not indicate who is using them. An 
entry is made for each pack assigned to a job in the 
job's share table. The share table is part of the 
demand file ent ry . 



DEADLOCK PREVENTION 
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To control overcommitment and prevent deadlock for 800/1600 and 
1600/6250 cpi, 9- track tape drives, resource identification by 
density is provided. The resource identifier NT is retained for 
upward compatibility; however, it can be used only to satisfy 
800 and 1600 cpi tape requests and cannot be specified 
concurrently in the same job with density resource identifiers 
HD (800 bpi, 9-track), PE (1600 cp i , 9- 1 rac k ) , and GE (6250 cpi, 
9-track). Assignment of a 9-track tape with no prior demand 
count defaults to the density resource specification. Density 
resource identifiers L0, HI, and HY are also provided for 
7-track tape units; however, they all map into the MT resource 
demand entry. 
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In the overcommitment algorithm, unsatisfied NT resource demands 
are Logically satisfied by 800/1600 cpi, 9-track drives; however, 
if at request time the desired 1600 cpi tape is found mounted on 
a 1600/6250 cpi drive, the assignment is made if it does not 
cause overcommitment. 

For jobs with HD, P E , or GE resource demands, RESEX attempts to 
satisfy the PE demand (in the overcommitment algorithm) with any 
9-track drives remaining after the job's HD and GE demands have 
been logically satisfied. 

For a job with a PE resource demand, if the desired 1600 cpi, 
9-track tape is found mounted on any 9-track drive, the 
assignment is made, unless it causes overcommitment or an 
internal conflict. Internal conflict is when tapes are 
attempting to be assigned to a job such that the current request 
would deadlock the job. For example, on a system with two 
800/1600 and two 1600/6250 cpi, 9-track drives, a user job with 
resource requirements of P£=2 and G E = 2 deadlocks itself if a PE 
tape found mounted on a 1600/6250 drive is actually assigned. 
Since this assignment cannot be allowed and the job cannot 
continue until that tape is dismounted from that drive type, 
RESEX informs the operator that this situation has occurred via 
the E,P display. 



OVERCOMMITMENT ALGORITHM 

The overcommitment algorithm has two basic parts, the 
environment and overcommitment determination. The environment 
and the demand for its resources are examined by RESEX to 
determine if the assignment of resources in the environment is 
such that a deadlock exists. The algorithm itself determines 
that there does or does not exist a sequence of job completions 
such that all jobs with assigned resources will complete. If 
all jobs with resources can eventually complete, then a deadlock 
does not exist. 

Subroutine BRE (build resource environment) examines the EST, 

MST, and the UDT from MAGNET and builds two working tables, the 

RET and EVSB, for use by the overcommitment algorithm. Figure 
12-1 contains the flowchart for BRE. 
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GRL 




yes 



;et resource 
list index 




no 



resource 
environment 
error (REV) 



Figure 12-1. BRE - Build Resource Environment 
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Figure 12-1. BRE - Build Resource Environment (Continued) 
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Figure 12-1- B RE ~ Build Resource Environment (Continued) 
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Figure 12-1. BRE - Build Resource Environment (Continued) 
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The RET consists of a combination of data collected from the EST, 
MST, and UOT tables. It contains one-word entries and is the 
same length as the EST. The format of an RET entry is as 
f o I lows : 



59 




47 


44 


41 


38 


35 


29 


23 




11 







dt 





cu 





ou 


eq 


ne 


ei 




flags 





Field 



dt 



cu 
ou 
eq 
ne 

ei 

f lags 



Desc ription 



Origin 
Tapes Packs 



Device type if bit 59 is zero; UDT/UST1 EST 
otherwise dt is an index into a 
table of equivalent resource 
types 



Current number of units in chain 

Original number of units in chain 

Equipment number (EST ordinal) 

Pointer to EST entry of next 
pack in chain 

EVSB index + 2 (if any) 

Each bit defined as follows: 



EST 

MST/STLL 
UDT/UST4 EST 

MST/STLL 



Bit 
11 

10-4 

3 

2 

1 





Desc ri pt ion 

Checking labels done UDT/UVSN 
by MAGNET 

Unused 

LDAM equipment 

End of chain of packs 

Unused 

Unit logically assigned 



EST 
MST/PF6L 
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The env i ronment VSN buffer contains data relating to mounted 
magnetic tapes and removable packs. An EVSB entry is two words 
of the following format. 



59 53 


47 


jj 


23 




17 


8 


5 


volume serial number or pack name 





uc 


ri 


eq 


flags 


sharers 


udt/mst 


job sequence number 



Field 



r i 



uc 



eq 

flags 



sharers 
udt/mst 



Description 

Resource index; points to a word in the demand file 
entry between RMTP and RQPD 

Unit count (1 to 8 ■) for packs; always 1 for tapes 

Equi pment numbe r 

Each bit defined as follows: 



i t 



Description 
Assigned 
Scratch VSN 

Unloaded pack with users 
Default VSN 
Unused 



53 

52 

51 

50 

4 9-48 

Number of users sharing pack 

UDT address if tape, or MST address/10B if disk 
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The overcommitment algorithm considers only those jobs that have 
currently assigned resources. A scratch file is bui t f™"-*;* 
demand file entries for those jobs. Each scratch file entry is 
then processed sequentially. If there are unsatisfied demands 
for a given entry, an attempt is made to determine if sufficient 
logically free resources are available to fulfill the demand. 
If all the resource demands for the job are satisfiable, then 
the job is said to complete. Jobs that complete have their 
resources logically freed for use by other jobs. 

If a job's demands cannot be satisfied, the demand entry is 
written to a second scratch file. Processing continues with the 
next entry in the first scratch file until it is exhausted. At 
the end of the first scratch file (a pass through the algorithm) 
if there are no uncompleted jobs (second scratch file is empty), 
then the algorithm has successfully completed and, based on the 
snapshot of the environment used during the execution of the 
algorithm, no deadlocks on resources will occur. If entries had 
been written to the second scratch file and some job did 
complete during this pass (the number of entries on the first 
and second scratch files are not equal), the scratch f i les are 
interchanged and another pass through the algorithm is made. If 
no job completed on a pass through the algorithm (both scratch 
files are identical), then there is a deadlock on the resources 
and overcommitment is said to have occurred. The overcommitment 
algorithm determines whether or not a deadlock will occur; the 
action taken by RESEX to prevent the deadlock is detailed later 
in this section. The overcommitment algorithm, OCA, is shown in 
figure 1 2-2 . 



RESOURCE FILES 

To aid in the allocation of magnetic tape and removable pack 
resources, RESEX maintains two mass storage files. These files 
are known as the resource files and are fast a" 80 *' J"" T"* 
access permanent files. The resource demand file (RSXDid) 
contains the maximum concurrent demand for each resource type. 
It also contains the share table and information for the preview 
display. The format of the RSXDid file is in figure 12-3. 
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The eq field of each share table entry contains the EST ordinal 
of the shared device; ri and uc specify t he resour ce_^ridex and 
unit count for this device (defines a location in 



RRPP) 




its lost tapes, it will be aborted with the following message 
issued when attempting a subsequent RESEX operation. 

PRIOR TAPE ASSIGNMENT LOST. 



he job aborts with the following mssage when attempti.ng a 
ubsequent I/O operation on a lost tape (any CIO function oth 
UNLOAD, or EVICT) . 

I/O SEQUENCE ERROR ON FILE, f.ff-AT nnn. 



T 

subseq 

than RETURN, 



e r 



job returns 



all of .its lost tape files, RESEX 



cle^s'the^^t^ape^^si'gn^nt'flag in the user • s demand f i le 
entry and the job can resume normal execution (pertinent to 
terminal and D IS users). 
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Figure 1 2-2 - OCA - Overcommitment Algorithm 
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Figure 12-2. 0CA - Overcommitment Algorithm (Continued) 
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Figure 12-2. OCA - Overcommitment Algorithm (Continued) 
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59 56 53 47 


35 23 


17 


11 


8 


5 





RJSQ 


job sequence number 


. 


RJBN 


job name 


;. 


RVAL * 


ipe pock ( 
kjI. vol. ' 


■ 
> 


unused 




total assigned 


total demand 


RMTP 


M" 


r c 


jssigned 


demand 





RNTP 


NT 


assigned 


demand 


. 


RPEP 


PE 


assigned 


demand 





RHDP 


HD 


assigned 


demand 





RGEP 


GE 


assigned 


demand 





RRPP 


DI 


ADO) 


AD(2) 


ADO) 


AD(4) 




mpu 


AD(5) 


AD(6) 


AD.(7) 


AD(8) 




DJ 


ADU) 


AD(2) 


ADO) 


AD(4) 




mpu 


AD(5) 


AD(6) 


AD(7) 


ADO) 




DK 


AD(1) 


AD(2) 


ADO) 


AD(4) 




mpu 


AD (5) 


AD(6) 


AD(7) 


AD(8) 




DL 


AD(1) 


AD(2) 


ADO) 


AD(4) 




mpu 


AD(5) 


AD(6) 


AD(7) 


AD(8) 




MD 


AD(1) 


AD(2) 


ADO) 


AD(4) 




mpu 


AD(5) 


AD(6) 


AD(7) 


AD(8) 


RQPD 




VSN or pac 


:k name 




resource type 


RQPU 




user nun 


nber 




flags 


FST address 


RQPT 





time 


RRPS 


pack name 


eq 





uc 


ri 




• 
• 
• 


• 
• 

• 


• 
• 
• 


• 
• 
• 


• 
• 
• 



3 7-track 

4 9- track (800/1600 cpi) 

5 1600 cpi 9- track 

6 800 cpi 9 -track 

7 6250 cpi 9 -track 

10 844-21 (1 to 8 units) 

11 half-track 

12 844-41 (1 to 8 units) 

13 half-track 

14 844-21 (1 to 8 units) 

15 full-track 

16 844-41 (1 to 8 units) 

17 full-track 

20 841 (1 to 8 units) 

21 

22 Preview data 

23 

24 

25 Share table 

• 

77 



Figure 12-3. Resource Demand File Entry (RSXVid) 



60454300 A 



12-15 



The VSN file (RSXVid) contains the volume serial numbers 
associated with a particular file (refer to figure 12-4). The 
entries in the VSN file contain the random index of the job's 



entry in the demand file and the 
tape within the demand file. The 
associated with a particular job 
sequence number. Entries in both 
I engt h . 



resource index of the assigned 
entries in these two files are 
and are identified by the job's 
files are one PRU (64 words) in 



These files are updated by RESEX and PP routine ORF. Routine 
ORF (described later in this section) updates demand and VSN 
file entries upon the return/unload of a tape file or the job's 
last direct access file on a pack and at job completion. 



59 



35 29 23 17 



5 



00 



01 



02 



03 



04 



job sequence 


unused 


job name 


unused 


logical file name 


unused 


unused 


uc 


ri 


demand file index 




volume serial number 


s 


unused 


en 


«. 




• 













77 8 



VJSQ 



VJBN 



VLFN 



VDFI 



VVSN 



uc Unit count (always 1) 

ri Resource index; points to a word in the demand 

file entry between RMTP and RGEP; zero if tape 
i s not yet assi gned 

s Scratch VSN (if set) 

en Control byte as follows: 

Value Meaning 



Mu 1 1 i ree I 

A 1 1 ernat e ree I 

End of ent ri es 



Figure 12-4. VSN File Entry (RSXVid) 
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Resource Satisfaction 

The Logical satisfaction of unfulfilled demands is done by 
subroutine determine demand satisfaction (DDS). DDS works with 
the RET and a temporary table called the resources demanded 
table (RDT), w h ich is formatted as follows: 



59 


53 


47 


41 


35 


29 


23 


17 


11 


5 


r 


t 


uc 





f 


oe 


E1 


E2 


E3 


E4 


E5 


E6 


E7 


E8 






rt 
u c 
f 

oe 
E1-E8 



Resource type 

Unit count (1 to 8 for packs, 1 for tapes) 

Flags 

Original equipment 

Equipments being used to (logically) satisfy the 
demand 



The RDT consists of the number of unsatisfied resource demands 
for the job. The satisfaction of tape demands by DDS is 
simplified since there is only one user for each tape. However, 
with removable packs there can be sharing and combinations. 
Sharing is having more than one accessor for each pack. The 
number of user jobs sharing a pack is reflected in the EVSB 
entry for that pack. It contains a count of the number of 
demand file entries that contain a share table entry for that 
pack. However, it cannot be assumed that a pack is going to be 
s ha red . 

The combination of removable packs allows the use of two DI-1s, 
for example, as a DI-2. The ability to combine removable 
equipments requires that a best bit determination be done by DDS; 
thus, the removable mass storage devices are used in a most 
efficient manner while logically satisfying demands. Mass 
storage demands are satisfied in a largest-numbe r-of-spi nd les- 
first order. This assures that the best fit is based on the 
smallest unused spindle residue of combinations of removable 
devices. The operator's choice of removable pack mounting can 
cause an excessive amount of overcommitment, as the best fit of 
removable packs may not be available for a given job. Refer to 
figure 12-5 for a flowchart of DDS. 
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Figure 12-5. DDS - Determine Demand Satisfaction 
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Figure 12-5- DPS - Determine Demand Satisfaction (Continued) 
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Figure 12-5. DDS - Determine Demand Satisfaction (Continued) 
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Resource Assignment Counts 

The method of assigning units depends on the resource type. 
ALL tapes and private packs not accessible by a 1 1 ernate users 
can only be assigned to one job at a time. All public packs and 
those private packs accessible by alternate users can be shared 
and, therefore, assigned to several jobs at the same time. 

On indirect access file requests, the pack is charged (assigned) 
to the job in fulfilling its resource demand on ly i f the 
requested pack must be mounted. For direct access file requests, 
the pack is charged to the job when the first direct access 
(ATTACH or DEFINE) is made. 

A unit is assigned to a job until the job termi nates, or when 
all the direct access files residing on that unit that are_ 
assigned to the job are returned/ un loaded, or a tape file is 
returned/un loaded. 

The system keeps track of the resource usage in the demand file 
through the assigned and demand counts for each job. These 
values may vary during job processing. A user can increase or 
decrease demands through additional RESOURC statements. However, 
if the user attempts to decrease his demand below his assigned 
count or Increase'his demand such that a deadlock would occur, 
a diagnostic is issued to the user's dayfile and the 30b is 
aborted. 

The demand and assign counts are also adjusted when ^es are 
returned or unloaded. When a magnetic tape file or the last file 
assigned to the job residing on a removable pack is unloaded, 
the resource assign count is decremented (by routine ORF) . If 
the file was returned, the resource demand count is also 
Incremented, but only if all of the job's demands have been 
satisfied. Whenever there is only one concurrent resouce 
demanded by the job, both the assign and demand counts are 
cleared regardless of the RETURN or UNLOAD function used to drop 
the f i le 

RESOURCE EXECUTIVE 

The remainder of this section is devoted to the internals of 
RESEX. 

RESEX processes requests for magnetic tapes and r !"? v ;ble 
packs and manages the usage of these resources. The following 
control statements are processed by RESEX. 



ASSIGN 

LABEL 

REQUEST 

RESOURC 

VSN 



60454300 A 



12-21 



These control statements are described in detail in the NOS 
Reference Manual, volume 1. The control statements for 
removable packs are part of CPU routine PFILES and are also 
described in the reference manual. 



CONTROL STATEMENT PROCESSING 

The control statements processed by RESEX fit into three groups: 
assignment (ASSIGN/LABEL/ REQUEST) , resource declaration 
(RESOURC), and VSN association (VSN) . 
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Resource Declaration 

The specification of a job's resource demand is accomplished via 
a RESOURC control statement. The processing of the RESOURC 
statement includes the validation of resource types and 
determining if a change in resource specification will produce a 
deadlock or internal conflict. Figure 12-7 is a flowchart of the 
RESOURC routine. 

VSN Associ at i on 

The purpose of the VSN control statement is to associate 
magnetic tape volume serial numbers with the name of the file 
that will use these reels. The processing of the VSN statement 
includes building a VSN file entry for the file (and a demand 
file entry, if necessary). The processing of the VSN statement 
does not depend on MAGNET being active. The routine to process 
the VSN statement is also entered to process the VSN= control 
statement parameter that may be used on assignment cards. The 
flowchart for the VSN processor is shown in figure 12-8. 
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Figure 12-6. ASSIGN/LABEL/REQUEST - 
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Figure 12-6. ASSIGN/LABEL/REQUEST - 
Assignment Control Statements 
( Cont i nued) 
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Figure 12-6. ASSIGN/LABEL/REQUEST - 
Assignment Control Statements 
( Cont i nued) 
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Figure 12-6. ASSIGN/LABEL/REQUEST 
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Figure 12-7. RESOURC Control Statement 



60454300 A 



12-28 





CBP 



calculate 

resource byte 

position 



I 



enter new 

demand 

count 



adjust 

total 

demand 

count 



resource 

demand 

error 

(RDE) 





■WRES5 



Figure 12-7. RESOURC Control Statement (Continued) 
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Figure 12-7. RESOURC Control Statement (Continued) 
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Figure 12-8. VSN Control Statement 
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EXTERNAL CALLS 



he assignment of removable packs and magnetic tapes is 
vailable to the user at the macro and RA+1 function Lev 



also 
el. 



Tape requests use LFM functions 
PFM functions. 



and removable pack requests use 



RA+1 call either directly or 



If the user issues an LFM or PFM 
through a macro to assign a resource unit to the job, the ppu 
processor (LFM, PFM) initiates a call to RESEX at that job s 
control point. To avoid destroying the user's field length when 
RESEX is invoked from the PPU, the DMP= special ent ry poin t i s 
defined in RESEX. The calling of RESEX is done via the SPCW 
word in the job's control point area. 

The SPCW calling mechanism places, beginning at address SPPR of 
the field length, a copy of the SPCW word and a 20B word block 
of data (usually the user FET); RESEX is loaded and begins 
execution at the entry point specified in the SPCW call. Upon 
completion, RESEX sets a status in SPPR which is returned to the 
calling PP when RESEX relinquishes control. 



In addition to LFM and PFM, RESEX processes 
order to maintain compatibility with NOS/BE 
through SPCW is initiated by PP routine SFP 



the REQ RA+1 call in 
The call to RESEX 



External call refers to the processing of LFM, PFM, and REQ 

calls by RESEX. This is opposed to an internal call in which 

RESEX calls the tape assignment routines directly after cracking 
the tape assignment control statement. 

Figure 1-2-9 flowcharts the LFM external call and figure 12-10 is 
a flowchart of the REQ external call. 
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Figure 12-9. LFM External Call Processor 
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Figure 12-9. LFM External Call Processor (Continued) 
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Figure 12-10. REQ External Call Processor 
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RESOURCE ASSIGNMENT 




REQUEST control statements. 
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by RESEX upon entry at 
The user ' s FET (as 
ck name and resource 
or their defaults, 
It for use by the 
f ers contro L to 
e COM subroutine. If a 
EX rolls out with a 
request . If 
Lected to do error 
RESEX rolls out with an 
uest. If ep is not set, 
i agnos t i c . 



REMOVABLE PACKS OVERCOMMITMENT 




PFM/RRP is contained in figure 12-11 
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Fi gure 1 2-1 1 . 
PFM - PFM External Call Processor and 
RRP - Request Removable Pack 
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Figure 12-1 1 . 
PFM - PFM External Call Processor and 
RRP - Request Removable Pack 
( Cont i nued) 
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MAGNETIC TAPE 

RMT, flowcharted in figure 12-12, 
tape from MAGNET. Before exiting 
called by the assignment control 
and REQ external functions. TBD 
(TB) by mapping portions of the t 
values for use in the RESEX/MAGNE 
word count, overflow, unused bit 
according to the requested format 
TBD also establishes density and 
installation supplied values (TDE 
Finally, TBD ensures that combina 
conflicting results, such as spec 
processing options. For 9-track 
original 9-track density display 
block word DD . 



is called to request 
to RMT, subroutine T 
statement processor a 
builds the tape block 
ape descriptors (FET+ 
T call block. TBD co 
count, noise size, an 
, f rame size, and noi 
conversion mode using 
N, TCVM, and TDTR) as 
tions of parameters d 
ifying both ring-in a 
tape requests, TBD se 
(HD, PE, or GE) into 



a magnet i c 
BD i s 
nd from LFM 

definition 
8) i nto 
mputes the 
d f i 11 
se size. 

necessary . 
o not yield 
nd ring-out 
t s the 
request 



RMT builds the request block (refer to figure 12-13). The 
request block (words RQ, RS, RU RI, DD, and 01) forms a common 
set of input parameters to the overcommitment algorithm for both 
tapes and packs. RMT guarantees that the requestor has a demand 
file entry and a VSN file entry for the desired tape file. All 
tape requests must have these two entries before attempting to 
satisfy a request . 

RMT then calls subroutine COM. This subroutine identifies the 
unit that satisfies the request and performs deadlock prevention 
COM returns three results: missing VSN, overcommitment, and 
assignment permitted. If the VSN is missing, RMT formats an 
event using the VSN and rolls out using this event. If 
overcommitment occurs, the preview data is cleared and RMT 
performs a rollout with the overcommitment event. . 
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Figure 12-12. RMT - Request Magnetic Tape 
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Figure 12-12. RMT - Request Magnetic Tape (Continued) 
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Figure 12-12. RMT - Request Magnetic Tape (Continued) 
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Figure 12-12. RMT - Request Magnetic Tape (Continued) 
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Figure 12-13. Request Block (RQ) 
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If COM returns the status indicating the assignment is 
allowed, subroutine VUR is called. VUR reads the UDT from 
MAGNET to verify that the VSN has not changed and the unit has 
not been assigned to another job since the environment was 
established. If this is not the case, RMT processes this 
situation as if it were an overcommitment case. 

Next, VUR checks for wrong density if the write ring is out of 
the tape or the user requested the write ring out. If an 800 bpi 
tape is mounted on a 1600/6250 bpi drive or a 6250 bpi tape is 
mounted on an 800/1600 bpi drive, VUR returns to RMT with density 
mismatch status. RMT then sends an error code block to MAGNET to 
advise the operator of this condition via the E,P display and 
processes the assignment rejection as an overcommitment case. If 
VUR detects any other combination of wrong density on a 9-track 
drive, a warning message (MIS-MATCHING DENSITY) is issued. 

Next, the conversion mode from the UDT is compared with that 
requested by the user; a warning (MIS-MATCHING CONVERSION) is 
issued if these conversion modes are not compatible. Then 
file accessibility and volume accessibility are validated 
guarantee system security is maintained by not permitting 
unauthorized operations to be performed on the tape. The 
RESEX/MAGNET call block (figure 12-14) is then built, the 
equipment interlocked through LFM, and the call block sent 
MAGNET to activate unit assignment. The UDT is reread from 
to verify that the assignment is successful and then RESEX 
completes the FNT/FST entry for the tape file through LFM. 
message 



the 
to 



to 
MAGNET 

The 



EQuu ASSIGNED TO Ifn, VSN= vsn. 

is issued to the user and system dayfiles indicate the 
assignment of the unit to the job. 
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Figure 12-14. RESEX/MAGNET Call Block 



n updates the job's demand file entry, builds the preview 
buffer, and performs any file opening required. RMT 



RMT the 

display 

exits and cont ro I 

The format of the 



is returned to the routine 

preview display buffer is as follows 



that called RESEX. 
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59 



f lags 



VSN or pack name 



user number 
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11 



resource type 



flags 



FST address 



Each bit defined as follows: 



Bi t 

14 
13 
12 



Description 

Unlabeled 
R i ng out 
Ri ng i n 



COM SUBROUTINE 

The subroutine COM controls the identification of the tape 
or pack requested and the processing of the overcommitment 
algorithm. COM begins by calling subroutine BRE to build 
the working resource environment tables (RET, EVSB) from which 
the desired resource unit can be identified and the algorithm 
executed. COM performs a timed/event rollout with missing 
subsystem event if BRE detected that MAGNET is not active. If 
demand file busy rollout occurred when BRE attached the demand 
file, COM rerequests operator assignment of equipmnt if no VSN 
was supplied (contents of AA equals 0). 

Subroutine CRQ is called to identify the desired VSN to be used 
during tape assignment and to set up the demand file entry and 
preview data for further processing. 

Subroutine DEI is then called to determine if enough resource 
units are available in the environment to satisfy the job s 
demands. 

Then subroutine BSF is called to build a scratch file with the 
demand file entries for all jobs with assigned resources except 
the requestor. Subroutine OCA later adds the requestor's updated 
demand file entry on the scratch file before executing the 
overcommitment algorithm. Subroutines CRQ and BSF call 
subroutine CAU (count assigned units) to adjust the environment 
to reflect those equipments that are currently assigned. 
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Next, subroutine C FU is called to assign the resource unit to 
the job. This allocation involves the advancing of the assigned 
count for the resource type being assigned, updating RESEX 
working tables, and building the share table entry (if a 
removable pack is being assigned). If the desired tape or pack 
is not found, pseudoent r i e s are made in order that the 
overcommitment algorithm may still be executed. If a pseudo 
entry must be made or a SCRATCH tape request is being satisfied, 
CFU guarantees that the selected equipment will not cause 
internal conflict for the job. 

Subroutine CIC is called to check for an internal conflict. The 
requestor job is in a state of deadlocking itself if the 
requestor's remaining demands cannot be satisfied by the 
environment remaining after the requestor's currently assigned 
resources and the unit selected by CFU are eliminated. This can 
occur when the current request is for a 1600 bpi 9-track tape 
(PE resource) that is mounted on the wrong drive type (800/1600 
or 1600/6250) such that the remaining 800 bpi (HD resource) or 
6250 bpi (GE resource) 9-track tape requirements cannot be 
satisfied. In this case, COM rejects the assignment and sends 
an error code call block to MAGNET to inform the operator of the 
conflict via the E,P display, so that the tape can be mounted on 
the correct drive type. 



Subroutine CRC is called to determine whether the requesting 
routine completes with the assignment of this resource unit, 
so, the overcommitment algorithm is not entered as this job 
cannot cause a deadlock to occur. 



If 



The overcommitment algorithm is now executed by calling 
subroutine OCA. COM returns a status indicating 
overcommitment ( /STATUS /0V ) , missing VSN or packname 
(/STATUS/MV) , or assignment permitted (/STATUS/OK) to the calling 
rout i ne . 

COM is flowcharted in figure 12-15. 

Subroutine CRQ exits to C0M6 if rerequest operator assignment of 
equipment is necessary; to C0M7 if rerequest operator selection 
for duplicate VSN is necessary; or to C0M10 if wait for ready on 
selected unit is necessary. Subroutine CFU also exits to COM? if 
operator selection for duplicate VSN is necessary. 
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RESEX calls subroutine ROA to request the operator to make an 
equipment assignment via LFM function 26. ROA uses FET+1 to pass 
LFM the required device type (MT, NT, or if zero, any equipment), 
and for 9-track tape requests, and the display code for the 
required density (HD, PE, or GE) to be entered in the operator 
request message. If an operator choice for a duplicate VSN is 
necessary, ROA also passes the required VSN in FET+9 for display 
in the operator request message. LFM returns the device type of 
the assigned equipment, and for tape equipment assignments, the 
EST ordinal of the assigned unit in FET+1. 

PREVIEW DISPLAY 

The preview display (E,P) involves RESEX, MAGNET, and DSD. 
Information for formatting the preview display is put into a 
job's demand file entry if the desired tape or pack is not 
mounted, and the job can use the resource immediately (that is, 
a drive is available for the desired tape or pack and that 
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Figure 12-15. COM 
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Figure 12-15. COM (Continued) 
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Figure 12-15. COM (Continued) 
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Figure 12-15. COM (Continued) 
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Figure 12-15. COM (Continued) 
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resource can be assigned to the job without causing a deadlock). 
RESEX reads the demand file in sequential order and if the job 
has preview data, it becomes a candidate for previewing. The 
preview buffer is built in an order based on resource usage and 
time of request. The order is determined using the highest 
values computed by the following formula. 

H=( (A + 1 )*T)/(D-A) 

A Assigned count (total of all resources) 
D Demand count (total of all resources) 
T Time the request has been waiting 

transfer red to 



The preview buffer is 

function and is limited to 63 words 

jobs previewed by RESEX to 31 jobs 

using the data in 

jobs appearing in 

require a tape to 

density mismatch, 



MAGNET via the SIC monitor 
This limits the number of 
DSD formats the E,P display 
MAGNET'S preview buffer and the UDTs. All 
the preview buffer and those jobs which 
be mounted due to reel swap, ring conflict, 
internal conflict are displayed. 



o r 



ted by RESEX each time RESEX is called 
preview buffer is refreshed only by 
System activity, such as dropping a job 



The preview buffer is upda _, 

into execution. Thus, the preview buffer is ref reshed_only_by 

an- activation of RESEX. , , _,_ _ 

with a request previewed from the rollout queue, Joes not cause 

that ent ry to be 
activated by 



removed from the display until RESEX is 
anot her job. 



REPRIEVE PROCESSING 



During initializat 
processing to be 



tion, RESEX requests extended reprieve 

in effect for errors set by a terminal user 




assignments. If RESEX is interrupted while processing a 
critical code sequence, the reprieve processor (routine RPV) 




retries the attach several times before giving up, in 
tie preview data and E,P display are not cleaned up. 
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WAITING FOR DEMAND FILE. 

In rare instances the demand file assign count must also be 
decremented to keep the user resource assign counts and file 
assignments in synchronization. In this case, RESEX continues 
to retry the demand file attach until it is successful. 



ROUTINE ORF 

PP program ORF updates the demand file entry upon job completion 
or upon the return of tape or pack resources. The return (or 
unloading) of a tape file clears that file's VSN file entry. 

Routine ORF is called by REC (dur i ng deads tar t recovery of 
MAGNET), ODF ( ret urn/ un load or last disk file), 1CJ (clear 
demand file entry on job completion), 1DS (clear demand file 
entry on job RERUN or PURGE), 1TA (clear demand file entry on 
SALVARE cleanup), and PFM (decrement demand entry for GET on 
removab le pack) . 

Routine ORF has three modes of operation: clearing VSN file 
entries, updating demand file entries, and clearing the demand 
file entry. The clearing of the VSN file entry automatically 
prompts the updating of the demand file for tapes. Routine ODF 
determines whether the direct-access file being returned is the 
user's last file on the removable pack and prompts ORF to update 
the share table entry for the removable pack and adjust the 
resource counts for the resource type involved. Finally, ORF is 
prompted to clear the demand file entry for a job when that job 
is removed from the system. 

The flowchart of ORF is in figure 12-16. 
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pause 



Figure 12-16. ORF - Update Resource Files 
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yes / \ Y es 
MURF5H 




Figure 12-16. ORF - Update Resource Files (Continued) 
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set for 
channel release 
with no update 





set demand 

file random 

index 



set tape resource 
index and 
byte pointer 




change to 
option 3 




yes 




WURF6 



no 



/uiDJ 



Figure 12-16. ORF - Update Resource Files (Continued) 
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read share 
table entry 



save resource 
index and 
unit count 



clear 

share table 

entry 





PAU 



pause 



__© 



set up 

MAGNET 

call 



I 



/ TDAM 

/ ask MAGNET 
\ to return 

\ tape unit 





Figure 12-16. ORF - Update Resource Files (Continued) 
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calculate 

assigned/demand 

count byte 

address 



decrement 

resource 

assigned 

count 




F i gure 1 2-1 6 



ORF 



- Update Resource Files (Continued) 
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decrement 

total 

demand 

count 




yes 



-HURC3 




hang PP 



decrement 

total 

assigned 

count 






■WURC3 



set for 

update 

demand 

file entry 




Figure 12-16. ORF - Update Resource Files (Continued) 
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RESEX ORGANIZATION 

An outline of the subroutines and storage areas contained in 
RESEX follows. 

• FETs for: 

Requested file 
VSN entry file 

Resource demand file (RSXDid) 
VSN file (RSXVid) 
Scratch f i les 
SSJ= parameter block 
Control point area parameters 
Temporary storage (flags) 
COMSRSX 

Event skeletons 
Resource request block 

Overcommitment algorithm control (COM) and subroutines: 
BRE Build resource environment 
BRT Build resource demand table (RDT) 
BSF Build scratch file 
CFU Check for unit 
CIC Check for internal conflict 
CRC Check requestor completer 
CRQ Check request 

DEI Demand exceeds installation check 
OCA Overcommitment algorithm 
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Overcommitment utility subroutines: 
CAU Count assigned units 
DDS Determine demand satisfaction 
DLY Delay 

IAS Initialize assignments 
SDT Switch 9-track drive type 
Resource reservation subroutines: 
RMT Request magnetic tape 
RRP Request removable pack 
ROA Request operator assignment 
VUR Verify unit request 
Resource file subroutines: 

MVE Make VSN file entry 
RDF Read demand file 
SVE Search for VSN file entry 
UDF Update demand file 
URF Update resource files 
Preview display subroutines: 

BPD Build preview display 

EPD Enter preview buffer entry 
Utility subroutines: 

BEV Build rollout event 

CBP Calculate resource byte position 

CET Copy EST 

CFA Check file attach 

CLB Clear buffer 

CRM Check for resource match 

CRV Check resource validation 
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CTA Count total assigns and demands 
CTL Check track Limit 
CUP Clean up request 
END Ending sequences 
Utility subroutines (Continued): 
ERR Error processing 
G FN Get f ami ly name 
GRI Get resource index 
GRL Get resource list index 

IDE Initialize demand entry 

IRC Increment resource count 

IVE Initialize VSN entry 

OPN Open file 

PER Process error message 

PNE Process jobname error message 

PRO Process timed/event rollout 

PIT Process interrupt 

RPV Reprieve processor 

RSB Read subsystem block 

WSB Write subsystem block to MAGNET 
Common decks 

Buffers (overlay subsequent routines) 
Control statement processors (second overlaid group) 

LABEL 

RESOURC 

VSN 
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External call processors LFM and REQ 
Control statement utility routines: 

BVE Bui Id VSN f i Le entry 

CCR Check for conflicting resources 

CJV Check job validation 

MFE Make resource file entries 

SVI Search for VSN index 

TBD Tape block definition 

VDD Validate dependent defaults 
Preset code temporaries 
Preset code common decks 

Control statement processors (first overlaid group) 
ASSIGN and REQUEST 

External call processor PFM 

Control statement preprocessors CCP (control statement 
preprocessor) and PCV (preset control point values; 

Assemble magnetic tape options (AMO) which call any of 
the following processors: 

SCD SCI SNS 

CRD SPO 

FID SCV STD 

SFA STF 

NMD SFS STK 

RTC SID VSP 

RTD SLT WRL 
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Control statement processing subroutines: 

AOP Analyze optional parameters 

CLP Call POP (pick out parameters) 

ENF Enter numeric label field 

FSC File status check 

6RD Generate retention date 

ILF Ini t iali ze label FET 



External request subroutines CLF (convert LFM call to 
FET) and CSF (convert NOS/BE call to FET) 
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MAGNET/1MT 



13 



for NOS are controlled by the 



,agnetic tape executive (MAGNET). MAGNET executes at a control 
,oint and maintains information for RESEX (resou [ ce M ^f 1 ^ t l Ve . 
md the system. The E,P display is updated i n the MAGNET field 



E,T display information 



All magnetic tape operations 
m 

P 1 

and the sy 

length by RESEX and is displayed by DSD. j _ 

is taken from UDTs (unit descriptor tabLe) which are maintained 

by MAGNET. Certain tape commands (such as UP/DOWN channel and 

ON/OFF unit) are processed by MAGNET via the TDAM monitor 

function. CIO places tape read/write requests in the UDT in 

MAGNET also via the TDAM function. In addi t i on , MAGNET statuses 

unassigned tape units for conditions such as tape 

labeled/unlabeled and ring in/out. Refer to section 12 for 

information concerning RESEX. 

MAGNET/1MT STRUCTURE 

The tape subsystem consists of CP routines MAGNET and MAGNET1 , 
and PP routine 1MT. MAGNET is the run-time executive and 
processes requests from DSD, RESEX, and CIO. MAGNET1 is the 
MAGNET termination processor. 



The PP portion of the subsystem consists of 1MT (main 
and the following overlays: 

Overlay Desc ript ion 

3MA Initialize tape executive 

3MB Function reject processor 

3MC ERRLOG message processor 

3MD MTS/ATS ERRLOG message processor 

3ME MTS/ATS special message processor 

3MF Load conversion memory 

3MQ Drop PP processor 

3MH Control point/coded preset 

3Mi Complete use r FET 

3Mj Issue user messages 

3MK User job operations 

3ML Read function processor 

3MM Read long block processor 

3MN Read label processor 

3Mo Multifile auxiliary processor 

3MP Open operations 

3MQ Tape -posit ioni ng operations 

3MR • MMTC Read error processor 

3MS MTS/ATS read error processor 

3MT write function processor 

3MI) Write lotig block processor 

3MV Write label processor 

3MW MMTC Write error processor 

3MX MTS/ATS write error processor 

3MY Tape monitoring preset 

1LT Long block helper processor 



rout i ne) 
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Routine 1MT overlays itself extensively to conserve space. For 
example, it uses the 5-byte header on PP routines; therefore, 
extreme care must be taken when attempting modifications. 

All magnetic tape equivalences are defined in common deck 
COMSMTX. These equivalences are used by MAGNET, RESEX, 1MT, CIO, 
DSD, ORF, and 1DS. 

MAGNET CONTROL POINT INITIALIZATION 

The control point for MAGNET is initialized in the same manner 
as TELEX. That is, DSD calls 1DS to process the operator typein, 
n. MAGNET. Routine 1DS then calls 1MT to initialize the 
executive. Routine 1MT determines that this is an initial call 
and executes overlay 3MA to perform control point initialization. 

Overlay 3MA is also called for a level 3 recovery. Routine 1MT 
determines that it is an initialization call when the next 
statement index (byte 3) of word CSPW is zero. If this value is 
greater than or equal to CSBW+2, then it is a level 3 recovery 
call. The following is performed by 3MA for an initialization 
call. 

• Calls INI (initialize CPU) to store the job name of 
MAGNET in control point area word JNMW with system 
origin type set. Sets CPU priority to 76B. Sets MFL 
and MAXFL to 50K. 

• Calls SCC (set up control cards) to set the following 
control statements in CSBW of the control point area: 

MAGNET. 
MAGNET1 . 
EXIT. 
MAGNET1 . 

In addition, the next statement index pointer in CSPW 
(byte 3) is set to CSBW for initialization or CSBW+1 for 
leve I 3 recove ry . 

• Calls PCC (process control cards) to do the following: 

1. Requests 10 OB words of field length. 

2. Sets byte 4 of UITW in MAGNET to 1 as an interlock 
wo rd . 

3. Requests 1AJ to process the next control statement. 
For initialization, this is MAGNET and for a level 3 
recovery, MAGNET1 . 

4. Waits until MAGNET clears interlock word. 

• Calls LFT (load function table) to write the 1MT 
function table and DSD error messages to MAGNET starting 
with TFUN. 

• Calls SCS (set character tables). If the 63-character 
set is selected, the 64-character table is modified. 
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Calls EST (pre-process EST). The EST is searched for 
tape equipment and the channel numbers are saved. A bit 
for every tape channel is set in word CHAN in MAGNET 
(maximum of 4 channels). 

Calls LBC to load MTS (66x) buffer controller and to 
load conversion tables to MTS and ATS controllers. 

Calls BDW (build equipment definition words) to build 
byte of UST1 of the UDT for each tape unit and store 
in an initialization buffer in MAGNET1 starting with 
UINT. This is used later to build the UDTs. 

Calls BIW (build interlock words) to build the 
MAGNET/1MT communication words starting at location UITW 
in MAGNET low core. 

Set s i nter-cont rol point word (ICAW) of the control 
point area as shown in figure 13-1. 



59 



ICAW 



rcall 



47 



29 



real 



pbufl 



17 



pbuf 



rcall Length of RCAL 

real RESEX request block buffer 

pbufl Length of PBUF 

pbuf FWA of preview buffer (read by DSD 

to bui Id Preview display) 

Fi gure 1 3-1 . ICAW Word 

• Sets 760000 event to indicate that MAGNET is available. 

• Drops PPU. MAGNET is now in control. 

For a level 3 recovery, 3MA only resets the control statements 
and reloads the 1MT function table and DSD error messages into the 
low core of MAGNET. 



MAGNET INITIALIZATION 
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, execution begins at the preset routine 
nterface area from UITW+1 through TPRO, 

through UITW-1, and finally UITW. At 
s until 1MT is finished building the 
ords starting with UINT. 1MT signals 
shed by setting UITW nonzero. Next, PEQ 

UDTs (refer to figure 13-2), one for each 
REL is called to perform instruction 
in routine where the operation definitions 
tart at TDTAB and overlay the preset code. 
T in COMSMTX) UDTs are established in 

up a pointer word in RA+3 called UBUF, 
t of UDT entries. 
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59 53 



47 



35 



29 23 



17 



11 



UXRO 

1 UCIA 

2 UCIB 

3 UCIC 

4 UST1 

5 UST2 

6 UST3 

7 UST4 

10 UST5 

11 UST6 

12 UST7 

13 UST8 

14 UST9 

15 UBLC 



rs 



codes 



fn 



mode 



■ I external 
D CIO code 



FL 



eq 



dn 



skip count 



FET options 



p 

level / 

/ 



pa 



pb 



FET address 



record/request /return 
information MLRS 



FIRST 



un 



error 
iteration 



hp 



wp 



last good record 



error code 



LIMIT 



es 



tape block count 



error parameter (ep) 



word count 



ov 



format 



est 
ord 



ds 



user options 



den 



cv 



noise 



software 
options 



MTS/ATS detailed status 



MTS/ATS detailed status 



MTS/ATS format 



ATS format 



ATS unit status 



ATS unit status 



block -ID window 



block-ID window 



blocks read accumulator 



blocks written accumulator 



blocks 
skipped 



3-word block 
sent by CIO 



for 66X/67X 
units only 



Figure 13-2. Unit Descriptor Table Format 
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59 53 



47 



35 



29 23 







16 ULRQ 

17 UREQ 

20 UFLA 

21 UJSQ 

22 UBJN 

23 UUFN 

24 UVSN 

25 UFID 

26 UFSN 

27 USID 

30 UGNU 

31 UDAT 



MAGNET last request 



req 



shift 



proc addr 



B2 



B3 



X5 



stack flag 



job sequence number 




control 
point no. 



VSN 
index 



job name 



user number 



vsn 



sc 



dm 



VSN random index 



ot 



fam. 
index 



ec 



next UDT to 
display ptr. 



est. 
writ. 



vac 



reel number 



file identifier 



mf 



file identifier (continued) 



set identifier 



creation date 



fac 



generation 
version number 



file section number 



file sequence number 



generation number 



expiration date 



Figure 13-2. Unit Descriptor Table Format (Continued) 
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The fields of figure 13-2 are defined as follows 
return status (RS): 



r s 



fn 



RIP (1) Request in. progress 

NCP (2) Normal completion 

REQ (3) Requeue with delay 

ERR (4) Error return 

function number (FN): 



SED 


(1 ) 


Set equipment. 


definition 


CUF 


(2) 


Comp le te user 


FEt 


MAB 


(3) 


Is sue message 


and abort job 


FNH 


(4) 


Process funct 


i on 


SKP 


(5) 


Skip 




OPF 


(6) 


Open funct i on 




RDF 


(7) 


Read data 




RLA 


(10B) 


Read label 




WTF 


(1 1B) 


Write data 




WLA 


C12B) 


Write I abe I 





mode 



pa 



pb 



Mode CMD) 



Bi t 



1 1 
10 



7 
6 
5 
4 
2-3 



1 


Pa ramet e r 
values) 

Pa ramet e r 
values) 



Description 

Reverse (read data only) 

Set IN=0UT=FIRST; 

reverse (read Labels only) 

First pass flag 

E0R/E0F written 

Not used 

Coded 

200/204 control 

260/264 control 

0- PRU ope ration 

1 - E0R ope rat i on 

2 - EOF ope rat i on 
3- E0I ope rat i on 
Not used 
Not used 



f o r reve rse skip 
this operation 



wo rd 
wo rd 



(see individual functions for allowable 



(see individual functions for allowable 
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codes Internal CIO codes: 

0000B Read 

0002B Write 

0104B Skip forward 

4204B Skip backward 

4300B Backspace PRU 

6400B Rewind 

0500B Open 

4500B Open rewi nd 

0600B Close 

4600B Close rewind 

1000B Evict 

Note 



Bits 9-6 of internal code are used as 
an index into table TPRO by MAGNET. 

Set i f autoreca 1 1 

Set if data in buffer 

User supplied CIO request code 

Level number (74B-SKIPF, 0-SKIPEI) 
Equipment number (used to connect equipment) 
Unit down flag 

Channel designator (bit 4=first tape channel, 
bit 5=second tape channel, etc.) 

Unit number 

Hardware options (HP) 



a 

b 

e xt e ma I 
CIO code 

I eve I 

eq 

down 

dn 

un 
hp 



B i t Pes c ri pt i on 

11 Last operation write 

10 Last block E0R/E0F 

9 B lank t ape 

8 Not Used 

7 End of set 

6 Not used 

5 MTS cont roller 

4 ATS controller 

3-2 Unit speed for ATS/MTS units (0=100 ips; 
1=150 ips; 2=200 ips) 

1 GCR tape uni t 

9-track unit 
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e s 

ds 

wp 



user 
opt ions 



Extended status CES) (status 2 for 65X) 

Device status (DS) (general status for MTS/ATS, and 
status 1 for MMTC converted to. MTS/ATS format) 

Block - ID window pointer (points to most recent 
entry) 

User processing options (UP) 



ep 



den 



B i t Description 

11 Tape labe I ed 

10 Nonstandard label 

9-8 Label type (0 = A.N'SI; 1-3 = u.nused) 

7 Assigned message issued for this unit 

6 Next VSN message issued for current reel 
swap 

5-1 Not used 

Coded 



Error parameters (EP and EP+1) 
Read error recovery: 

EP,11 Reverse direction flag 

EP,10 Opposite parity mode 

EP,9 Not used 

EP,8-6 Clipping level 

E P , 5 - Re-entry code 

EP+1, 11-9 Clipping level being tried 

EP + 1 ,8-6 Retry count 

EP + 1, 5 - 3 Normal parity reread count 

EP + 1, 2-0 Opposite parity reread count 

Write error recovery: 



EP,1 1 

EP,10 

EP,9-0 

EP + 1 ,11-6 

EP + 1 ,5-0 

Density: 
D02 (1) 
D05 (2) 
D08 (3) 
D16 (4) 



Verify in p rog ress 

Erase error has occurred 

Not us ed 

Not used 

Numbe r of erases 



200 bpi 
556 bpi 
800 bpi 
1600 cpi 



D62 (5) 6250 cpi 
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C V 



word 
count 



ov 



Conversion mode: 

BCD (1) BCD conversion (7-track) 

ANS (2) ANSI conversion (9-track) 

EBC (3) EBCDIC conversion (9-track) 

Word count (WC), 0< WC < 512 

(for L-format tapes, WC is number of words in Last 

part i a L chunk) 

Overflow (OV); for F and L format, the number of 
chunks (600B words each) 



format Format ( FM) : 

TFI (0) Internal binary 

TFSI (1) System internal binary 

TFF (2) Foreign format 

TFS (3) Stranger binary/coded 

TFL (4) Stranger long blocks binary/coded 



est ord 

f i 11 

noi se 

sof t wa re 
opt ions 



EST ordinal of equipment 
Fill status (set if fill ok) 
Noise block size in bytes 
Software option (SP): 
Bits Pes c ri pt i on 

11-10 End of reel processing: 

Tape mark and trailer sequence, 
option 3, P0 = S 

1 EOT (accept PRU), option 2, P0=P 

2 EOT (discard PRU), option 1, P0=I 



9-8 

7 



Not used 

Issue all messages to user dayfile setting, 

P0 = M 

Disable error correction on GCR write, 

P0 = G 

Inhibit unload, P0=U 

Ring in required, P0=W 

Ring out required, P0=R 

Inhibit error processing, P0=E 

Accept data on RPE/WPE without ep set, 

P0 = N 

Abort RPE/WPE with ep set, P0=A 



req 



shift 



or 1, 3, 5, 7 if the request is stored in the 
QUEUE table 

Shift count (12, 24, 36, 48) used to shift a byte 
of a processor string entry to the low 12-bit 
pos i t ion 
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p roc 
addr 

s t a c k 



vsn 
i ndex 

ot 

est 

w ri tten 

vac 

vsn 

Ic 

S V 

ow 
dm 
ev 
ec 



<ll 
Le 
mf 
fa c 



Address of processor string entry 

If set, there are entries in the QUEUE table for 
t h i s uni t 

VSN index (pointer to word in VSN entry 
containing the VSN) 

Job origin type 

EST order of unit that the tape was written on 

Volume accessibility character 

VSN (6 character VSN) 

Label checking in progress (bit 23) 

Scratch VSN (bit 22) 

Open performed (bit 21) 

Density mismatch detected (bit 20) 

Equivalenced VSNs for this reel (bit 19) 

Error code for DSD display (bits 18-15): 

1 EQxx needs label 

2 EQxx cannot access data 

3 EQxx ring conflict 

4 EQxx wrong VSN 

5 EQxx dri ve conf li ct 

6 EQxx density mismatch 
17-7 Reserved 

Default label (bit 14) 

Label expired (bit 13) 

Mount flag (bit 12) 

File accessibility character 



Each UDT entry is UNITL (31B) words in length. PEQ sets the SED 
function (set equipment definition) in each UDT entry; therefore 
1MT will be called to determine the type of each unit. 

PEQ sets up another low core pointer, UQUE. UQUE specifies the 
first word address of the queue table which follows the UDT list 
and is initialized with 10B empty entries. The queue table is 
terminated by two words with all bits set. Figure 13-3 shows 
the memory map of MAGNET after initialization; figure 13-4 
illustrates a detailed map of MAGNET low core. figures 13-5 
through 13-14 detail portions of MAGNET low core. 
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TPRO 



MAG 



TDTAB 



4000 



7777 



7777 



Pointers 
Interlock words 
Function table 
DSD error messages 
External interface areas 



String processor table 



MAGNET main routine and subroutines 



Unit descriptor tables 



Queue buffer 
(10 empty entries initially) 



Low core 



0000 



End of UDTs 
indicator 



7777 



7777 



Terminates 
queue buffer 



Figure 13-3. Overview of MAGNET After Initialization 
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RA+3 
+4 
. +5 
+6 
+ 7 
+ 10 
4-11 
+ 12 
+ 13 
+ 14 
+ 15 
+ 16 
+ 17 
+ 20 
+ 21 
+ 22 
+ 23 
+ 24 
+ 25 

+ 26 

+ 27 

• 

+ 36 
+ 37 



UBUF 
UQUE 
USWP 
XREQ 

U.RIW 
CHAN 
NTAS 

UITW 



59 47 

Ptr. first Ubl 



35 



23 



11 







to display 



no. units 







Iwa UDT 







fwa UDT 



unit swap flag 



external request buffer 



interlocked request word 
channel status word 



number of tape units currently assigned 



1MT 



active flag 



1MT 



active flag 



1MT 



active flag 



1MT 



FLSW 
TMGF 
RCAL 



7 



active flag 



end of table 



field length status word 



monitoring 
channel 



tape channel 
index 



monitoringlMT 
IR address 



RESEX request block buffer 



TFUN 



+ 40 

+ 50 

+ 51 

• 

+6*4 

+65 

• 

+100 
+101 

+ 177 

+200 



1MT function table 



DMBF 



DSO message buffer 



TPRO 



preview display buffer 



fwa of queue 

UDT addr 

next y§N„ 



00I7 



2-word 
buffer 



monitored 
UDT address 



MAGNET- 1MT 
interlock words 

• 2 words/ 
channel 

4 channels 
maximum 



Indicates 
end of table 



10B words 




14B words 



14B words 



String processor table 



Figure 13-4. Detailed Map of MAGNET Low Core 



77B words 
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59 



47 



35 







XREQ 



fc 



udt 



parameters 



f c 



UDT 



Function code: 

Return uni t 

1 Enter VSN for unit (parameter 
= VSN numbe r) 

2 Un Load unit 

3 Scratch VSN 

5 ON/OFF unit (parameter = if 
ON unit, if OFF unit) 

UDT address 



59 



XREQ 



fc 



47 



35 



23 



UITW 



11 




cf 



f c Funct ion code : 

4 UP/DOWN channel 
UITW Channel status word index (1, 3, 5, 7) 
cf Channel function (0 = UP, 1 = DOWN) 
Figure 13-5. XREQ Format 



URIW 




udt 



UDT Address 



channel Channel status word index 
(1,3,5,7) 



f c 



Funct i on code : 

Interlock and reserve a unit 

1 Down a unit 



Figure 13-6. Interlock Request Word 
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CHAN 



3 




s Channel status; one bit for each 
tape channel - 4 maximum 
(0 = channel down, 1 = channel up) 

Figure 13-7. Channel Status Word 



59 



UITW 



1MT 



RTCL seconds 



35 32 28 23 



11 



chan 



E4 



E3 



E2 



El 



RTCL in milliseconds 



cm 



udt 



c 

chan 
E4-E1 
cm 



f 
udt 



Index (1,3,5,7) (bits 35-33) 
Channel down flag (bit 32) 
Controller type (bits 31-30) 

MMTC 

1 ATS 

2 MTS 

3 MTS without BID 
Dedicated channel flag (bit 29) 
Channel number (bits 28-24) 
Controller/equipment numbers 
Conversion memory (1=BCD, 
2=ANSI, 3=EBCDIC) if any required 
(MMTC only) 

Active/inactive flag (1=active) 
Pointer to last UDT processed 



Figure 13-8. MAGNET-1MT Interlock Words 



FLSW 



59 


29 


field length 


/ W^MMW/ / 



field length Current field length requested 
Figure 13-9. Field Length Status Word 
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59 



54 51 47 



35 



TFUN 







ovl 


7 

/ 

/ 
/ 


a 


b 


add 
ovl 


addr 


^^^^^^^ 



ovl Overlay name (1 character) 

a Function requires ready and not busy 

status 
b Do at user's control point 
add ovl Additional overlay to be loaded first 
addr Address of function processor 

(address within ovl to begin 

execution at ) 

Functions: 



Code Function 



SED 



Figure 1 3-1 . 



1MT 



2 


CUF 


3 


MAB 


4 


FNH 


5 


SKP 


6 


OPF 


7 


RDF 


10 


RLA 


11 


WTF 


12 


WLA 


Fun c t 


i on 



Description 

Set equ i pment 

definition 

Complete user's FET 

Is sue message ( s ) to 

user and abort job 

Process function 

Skip 

Open 

Read data 

Read labe I 

Write data 

Write Labe I 



Tab Le Ent ri es 
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e c 



Error code. If EC = 0, then check if 

any error flags set by system and 

return ef value to MAGNET in bits 
23-12. 




11 



fc 



s c 



f c 



Subfunction code: (for fc=6) 

Issue PRUs transferred message 

1 Issue tape unit assigned 
message 

2 Issue tape unit returned 
message 

Fun ct i on code : 

Rewi nd tape 

1 Unload tape 

2 Select density 

3 Clear job assignment 

4 Read VSN from VSN f i le 

5 Perform unit swap 

6 Issue message to account file 

7 Issue next VSN message for 
mu It i-reel 

10 Post message at MAGNET 
cont ro I poi nt 



Figure 13-11. MAB and FNH Function Requests 
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59 



47 



RCAL+O 



+ 1 



+ 2 



+ 3 



+4 



+ 5 



+ 6 



+ 7 



function 



35 29 23 17 11 5 



interlock 





ec 



user 
options 



UDT address 



word 
count 



overflow 
unused 
chars. 



sequence number 



format 





job name 



volume serial number (VSN) 



user number 



EST 
ord. 



VSN 
ind. 





noise 



density 



conv. 



software 
options 



VSN random 
address 



job 
orig. 




family 



Z 





23 



function Function code: 



Assign unit 

1 Set error code in UVSN word of 
UDT 



e c 



Error code for function 1 



Figure 13-12. RESEX-MAGNET Call Block 
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59 



17 11 







PBUF 



interlock word and length of buffer 



/olume serial number or pack name 



user number 



resource type 



flags 



FST addr 



2 words/ 
entry 



resource type 



flags 



MT, NT, PE, HD, GE, 01-1 
through DI~8, DJ-1 through 
DJ-8, DL-1 through DL-8, 
DK-1 through DK-8 

Ri ng in (bit 12), ri ng out 
(bit 13), Labeled (bit 14) 
(for tapes only) 



Figure 13-13. Preview Display Buffer 
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59 



47 



35 



23 



11 



TPRO + 
(PWDA) 

+ 1 



+ 2 



+3 



+4 



+5 



+6 



(PRDA) +7 



+ 10 



(POLA) +11 



+ 12 



+ 13 



LAB1 


WDA 


CWC + 
6000B 


WDA1 





PSKP 














PSKP 














PSKP 














FET1 


REW 











OPE 


POLA 











CLO 














LAB 


RDA 


CRK + 
6000B 








PMAB 














OPE 


4000B 


4000B 


4000B 


CLM+ 
6000B 


FNH 


RLA 


4100B 


4400B 


4000B 


0PE1 


FET1 






















Write 

Skip forward 

Skip backward 

Backspace PRU 

Rewind 

Open 

Close 

Rewind 
(special case) 

Evict 



First entry group contains the first nine entries in the 
table. Each entry in this group can have no more than four 
processors (Limited to one central memory word) because these 
entries are indexed by a portion of the internal CIO code. 
Read data is given special treatment. The second entry group 
contains the remaining entries in the table. There is no 
restriction on the length of these entries. 

Figure 13-14. Table of Processor Strings 
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1MT INITIALIZATION 

The initialization of 1MT each time it is Loaded consists of 
the following steps. 

1. If an initialize call or level 3 recovery call, execute 
overlay 3MA (described earlier in this section). 

2. Set up the number of control points. 

3. Set FWA, LWA+1 and length of UDT. 

4. Set processor number (one of 4 values, 1, 3, 5, 7). 

5. Set channel, enable/disable channel modification. 

6. Determine if conversion memory load needed (MMTC only). 

7. If MMTC controller, modify certain instructions. 

8. If ATS controller, execute controller diagnostic. 

9. Load conversion memory for 65X controller if needed. 
10. Preset controLLer options and exit to main loop. 

MAGNET RUN-TIME EXECUTIVE 

One of the main components of this module is the string 
processor table TPRO (refer to figure 13-14) . Each entry is 
generated at assembly time by the PROC macro which results in e 




indexed by the internal CIO function codes defined in common 
deck C0MSCI0 (refer to figures 13-2 and 13-14 for more 
information). If any changes are made to C0MSCI0, it may be 
necessary to make changes to the TPRO table. 

The first group of entries is a maximum of one word in length due 
to the indexing explained previously. The second group of 
entries have no restrictions for length except that they must 
terminate with a zero byte. In addition to containing entry 
point addresses, addresses of other strings or function codes, 
each entry may also contain parameters which are associated with 
thefunctioncodes. 

Up to three 12-bit parameters can be imbedded in a string per 
function code, but if less than three are given, the rest are 
assumed to be zero. A parameter is differentiated f™nran 
address or function code by the setting of bit 11 of a 12-bit 
byte. The three parameters, if specified, are referred to as MD, 
PB, and PA respectively. These parameters are stored along with 
the function code in word UXRQ of the UDT when making a request 
of 1MT. 
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If a byte within a string entry has bits 10 and 11 both set, it 
means that an error occurred in processing the last function 
requests. The processor defined within this byte should be 
executed and the rest of the string should be skipped. 
Otherwise, the byte is ignored if no error occurred. This byte 
contains either an address of a processor routine within MAGNET 
or an address of another string. 



MAGN 
t i me 
ma j o 
c he c 
queu 
i f a 
any 
c a nn 
c omp 
a s s i 
bloc 
This 
rout 
a TL 



E T ' s ma 
count e 
r sub ro 
ks all 
e table 
ny are 
request 
ot be p 
lete th 
gnment 
k) . IU 
is use 
ine PPU 
X call. 



in loop consists of the following: update internal 
rs and if necessary reduce field length, and execute 
utines CUT, CXR, ASU, IUN, and PPU. Routine CUT 
UDT entries for outstanding requests from CIO. The 

is also searched for any outstanding requests, and 
found, they are processed. CSR is caLled to process 
s from DSD/1DS or QDF/ORF. Since certain requests 
rocessed completely by CXR, it makes queue entries to 
e external request. ASU is called to perform unit 
as requested by RESEX (RCAL contains the request 
N processes requests to interlock and reserve a unit. 
d by 1MT when a CONNECT operation fails. Finally, 

is called to activate a copy of 1MT if necessary via 



Routine CUT causes nearly all secondary request processing 
routines to be executed. These secondary routines return to CUT 
via one of the following exit points when completed. 



Exit Point 
EXIX 
EXIT 
EXI1 

EXI2 

EXI3 
EXI4 

EXI5 



Description 

Process next unit (next UDT entry) 

Process next request for this unit, if any 

Clear current request (UREQ=Q) and enter 
new request 

Make request to 1MT (set function code and 
values for parameters MD, PA, PB in UXRQ) 

Empty request queue and make new request 

Queue new request; store in UREQ and if 
there is an outstanding request already in 
UREQ, move to the queue table 

Requeue operation; store the original 
request back in UREQ 



The following are string processing subroutines. 
Routine Desc ri pt i on 



GPI 



Get parameter item if next in the string 
The next byte in the string is picked up 
and returned if bit 11 is set which 
indicates it is a parameter. 
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Rout ine 



GNR 



MQE 



Desc ri pt ion 

Get next request. If request is already 
present in UREQ, it is returned. Otherwise 
a search of the request queue table is made 
for the next request for this unit. 

Make queue entry. lEnters new request 
string in UREQ and stores the original 
request from UREQ (if one is present) in 
the request queue table in LIFO order. 



■o figures 13-4 through 13-14 for formats of MAGNET'S low 
md figures 13-2, 13-15, 13-16, and 13-17 for detailed 



Refer t< 

core; and figi 

descriptions of the UDT and other tables used by 

Table 13-1 describes MAGNET processing options. 



MAGNET and 1 MT 



ROUTINE 1MT 

MAGNET calls 1MT to perform certain tape operations that were 
initiated via a CIO call, DSD/1DS request, or a RESEX request 
and periodically calls 1MT to perform initial label check. In 
general, 1MT searches through the entire UOT for requests to 
process. The first word of each UDT entry contains the request 
if there is one. The function code in this request is used as 
an index into the TFUN table stored in MAGNET low core to get 
the proper overlay to load and starting address for execution. 
As requests are completed, a return code is placed into the 
first word of the UDT entry (byte 0). 



If there is only one tape channel, then there can be only one 
copy of 1MT active at any one time. If two channels, then two 
copies of 1MT can be active at any one time. There can be a 
maximum of four tape channels. If there is one channel, then 
the one copy of 1MT processes all the UDTs. If there is more 
than one channel, then each copy of 1MT processes only the UDT 
entries for a particular channel. 



TAPE MONITORING 

MAGNET and 1MT have capabilities for monitoring tape controller 
dialogue, for use in conjunction with an internal tape testing 
tool consisting of CPU program and a PP program. Word TMGF of 
MAGNET low core indicates to 1MT that monitoring is in effect 
for the tape unit specified by the UDT address. When processing 
this unit, 1MT modifies its channel instructions to use the 
monitoring channel so that all tape controller functions for thi 
unit are sent to the tape test PP program for logging before 
being relayed to the ATS or MTS tape controller. This tool is 
especially useful for analyzing tape error recovery processing. 
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FST 




47 



eq. no. 



UDT addr. 



35 31 29 



11 



for- 
mat 



m 



VSN random address 



status 



format 



status 



Format 

1 
2 
3 
4 



of tape: 
I format (internal binary) 
SI format (System internal binary) 
F format (foreign) 
S format (stranger b i na ry / c oded) 
L format (stranger long block 
binary/ coded ) 



Label flag: 

Tape unlabeled 

1 Tape labeled 

Status of file: 

Bits Desc ript i on 



10-1 




Not used (information is kept in UDT 
Set if function complete; not set=busy 
status 



Figure 13-15. FST Entry for Tapes 
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EST 




29 



chD 



chC 



23 



device 
type 



11 8 



FT 

/ 
/ 

/ 

41 



mt- 1 
at J 



3 

unt 
no 



I 



gc 
L db 



of 

mt 
at 
db 

gc 



ON/OFF flag (set if access not 

a I Lowed) 

MTS tape unit (bit 8) 

ATS tape unit (bit 7) 

Disable block-ID for MTS unit (bit 5) 

GCR tape unit (bit 4) 



Figure 13-16. EST Entry for Magnetic Tapes 
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UXRQ 



59 




47 




35 




23 


17 


11 







RS 


FN 


MD 


PA 


PB 


«% 




















V 



UST1 



UST2 



UST3 



UST4 





















ED 


HP 


EC 


ES 


DS 


£1 


WP 


BL 


UP 


LG 


EP 


DC 


WC 


OV 


FM 


EO 


NB 


SP 





















Figure 13-17. 1MT Direct Cell ALLocation 
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TABLE 13-1. MAGNET PROCESSING OPTIONS 



Byte 

Def i ni t ion 



Dec . |Oct . 



Mode(MD) 



User Options 
(UP) 



Software Options 
(SP) 



Not used 



Coded 



Abort RPE/WPE 
with ep set, 
P0 = A 



Not used 



Not used 



Accept data on 
RPE/WPE without 
ep set, PO=N 



Code I Read | Wri te 



Not used 



|PRU | PRU 

1 |E0R iBuffer 

2 j EOF i EOR 

3 | EOI | EOF 



Inhibit error 
process i ng, 
P0 = E 



Not used 



Ring out 

requi red, P0 = R 



260/264 mode 



Not used 



Ring in 

requi red, P0 = W 



200/204 mode 



Not used 



Inhibi t unload, 
P0 = U 



Coded 



Next VSN 
message issued 
for current 
reel swap 



Di sab le GCR 
hardwa re write 
correction 



Not used 



Message 

as s i gnment flag 



Issue all 
messages to 
user dayf i le 



10 



E0R/E0F written 
this operat i on 



Not used 



Not used 



11 



Not used 



Not used 



Not used 
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TABLE 13-1. MAGNET PROCESSING OPTIONS (CONTINUED) 



I Byte ' 

{Definition! I . 

i „«- i moHp(md) I User Ootions Software OptionsI 


iDec. lOct. | 1 CUP) 1 (SP) 1 


III | I End of reel I 
|10 | 12 | Set IN = OUT = | Nonstandard I ! 
| | | FIRST (reverse j LabeL I 0-tape P0=S I 
| | | read LabeL l I mark I 
| | | only) I I 1-EOT P0=P I 

III | I PRU) I 
| 11 | 13 | Reverse (read I LabeLed I 2 - E T P0=l| 
I | | data) I I (discard I 

I I PRU) I 
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TABLE 13-1. MAGNET PROCESSING OPTIONS (CONTINUED) 



yt e 

ef i ni t ion 



ec. |Oct „ 



Hardware Options 
(HP) 



9-t rack 



Device Status 
(DS) 65X 



Tape ready 



xtended Status 
ES) 65X 



Vertical and/or 
longi tudi na I 
pa ri ty error 



GCR tape unit 



Read/ wri te 
cont rot and/or 
tape unit busy 



Memory parity 
error 



Unit speed for 
ATS/MTS units 

- 100 ips 

1 - 1 50 ips 

2 - 200 ips 



Write enable 



F lag bi t error 



Fi le mark/tape 
mark detected 



CRC error 



ATS 

cont roller 



Load point 



Multi-track 
phase error or 
uncorrect able 
CRC e rror 



MTS controller 



End-of-t ape 



Character fill 



Not used 



End of set 
encountered 



Dens i ty 



0-200 bpi 
1-556 bpi 
2-800 bpi/cpi 
3-1600 cpi 



Character 
c rowdi ng or 
dropout and 
false end-of- 
operat i on (NRZI 



Phase error 
correction 



10 



Not used 



Lost data 



False pos tamb I 
detected 
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TABLE 13-1. MAGNET PROCESSING OPTIONS (CONTINUED) 



Byte [ | | 
Def i n i t i on | | j 


1 Hardware Optionsl Device Status [Extended Status 

Dec. |0ct. | (HP) j (DS) 65X |(ES) 65X 


9 | 11 j Blank tape | End-of- | End-of- 
I I I operation | operation 


10 I 12 | Last block | Alert | Alert 
I j EOR/EOF | | 

11 I 13 J Last operation | Tape unit | Cold start 
I | write | reserved | 
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TABLE 13-1- MAGNET PROCESSING OPTIONS (CONTINUED) 



Byte 

Def i ni t ion 



Dec- | Oct 



General Status 
66X/67X 



Unit ready 



Unit busy 



Load point 



End-of-t ape 



Tape mark 
detected 



Odd count 



Unit type 

= 7-track, 

1 = 9-track 



Write ring 



10 



Noi se detected 



11 



No uni t 



10 



12 



Coupler status 
(not used 
lower CYBER) 



11 



13 



A lert 
write 



reserved 
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RESIDENCY OF 1MT 

The following is a suggested order of priority for making 
routines CM or alternate library residence. 

1. Function reject processor (3MB) 

2. Control point/coded preset (3MH) 

3. Read function processor C3ML) 

4. Write function processor (3MT) 

5. Drop PPU processor (3MG) 
6 . 1MT i tself 

7. Complete user FET (3MI) 

8. Read label processor (3MN) 

9. Read/write error recovery overlays, 3MR and 3MW, for 
65x units and/or 3MS and 3MX for 66x/67x units 
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PERMANENT FILE MANAGER 



14 



Permanent files are controlled by PP routine permanent file 
manager (PFM) . All requests for permanent file action are 
accompanied by a specific user number. User numbers 
are es tab li shed by the installation and entered into the system 
validation file VALIDUs. Each user number then maps to a user 
index. Only validated users may request permanent file action. 

PFM COMMUNICATION 

PFM is called using the following RA + 1 request. 

59 40 ,._35_ 23 17 

RA+1 



PFM 



/ 



code 




addr 



r 
code 



Auto recall (bit 40, must be set) 
Command code (request): 



Symbo I 

CCSV 
CCGT 
CCPG 
CCCT 
CCPM 
CCRP 
CCAP 
CCDF 
CCAT 
CCCG 



Octal 
Value 

01 
02 
03 
04 
05 
06 
07 
10 
11 
12 



Command 

SAVE 

GET 

PURGE 

CATLIST 

PERMIT 

REPLACE 

APPEND 

DEFINE 

ATTACH 

CHANGE 



addr 



Address of the call block or FET 



The code parameter is biased by 2000B if the default pack name 
is to be ignored or by 1000B if the default family is to be used 

The RA+1 call is either generated directly by the user or is 
generated by a PFM macro or control statement. Macros that use 
PFM are described in volume 2 of the NOS Reference Manual. PFM 
control statements are described in volume 1 of the NOS 

Reference Manual. 

A PFM control statement causes CPU routine PFILES to be loaded 
in the user's FL. PFILES issues the PFM macro calls which 
result in an RA + 1 request for PFM . 

The FET used by all PFM requests is of the following form. 
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59 53 47 44 



23 17 11 5 



FET + O 




+ 8 



+9 



-4-10 



+ 11 



+ 12 



+ 13 



+ 14 



+ 15 



V7 



permanent file name (pfn) 



ouan 




A 



dn 



7 



file password (pwd) 



erad 



user control word (ucw 



CFSN 




CFPN 
CFCT 
CFMD 

CFOU 
CFPW 
CFUC 
CFPK 
CFNF 
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status 
c 

dt 



Error codes are returned in bits 17-10. 



up 

ep 

I 

pf n 
s r 



ct 



Bit is set to one upon comp 
request . 



Letion of the 



Device type of file residence. If not 
specified, system default is used (DI for 
auxiliary device requests; any available 

device for others). 

User processing bit (bit 45). If s( ;t/ 
control is returned on device unavailable 
errors. 

Error processing bit (bit 44). If set, 
control is returned to the user on errors. 

FET length mi nus 5 . 

Permanent file name. If zero, Lfn is used 

Special request:* 

Symbol Description 

Fast attach 

CATLIST of specific device 

C lear error status 

Force non-fast attach 



SRFA 
SRDN 
SRCE 
SRNF 



File category:* 

Symbol Description 

F CPR Private 

FCSP Semipr i va te 

FCPB Public 

File access mode : * 

Symbol Description 

PTWR Write 

PTRD Read 

PTAP Append 
PTEX Execute only 



Symbols defined in common deck COMSPFM 



* by 
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ouan** 

dn 

s** 



pwd 
e rad 



ucw 



pn 



unit 



nf n 
ss 



Symbol* Desc ri pt ion 

PTNU NuLL 

PTMD Modify 

PTRM Read/modify 

PTRA Read/append 

PTNM Nonroll modify (IAUM onLy) 

Alternate user number. 

Device number for CATLIST function. 

Number of PRUs required for the direct 
access permanent file being defined. This 
ensures that s PRUs are available when the 
file is defined, but does not necessarily 
ensure they will be available to write 
(that is, they are not prea I located) . 

Optional file password. 

Address where error messages are returned. 
The message may be up to three words long 
and is stored at the given address only if 

ep is set. 

Program control word. If bit 59 is set, 
whatever the user stores in this word is 
stored in the catalog entry when a 
permanent file is created, or a CHANGE, 
REPLACE, or APPEND is performed on it. 
This word is read from the catalog entry 
and stored in CFUC when the file is 
attached. (Bits 14 through 12 contain the 
time-sharing subsystem code.) 

Name of the auxiliary device to be used in 
satisfying the permanent file request. 

The number of units of the type specified 
by dt. For example, if the device type is 
DI4, the dt field contains DI and the unit 
field contains 4. If dn is nonzero and 
unit equals zero, then a default of 1 is 
used . 

New file name used with the CHANGE command 

Subsystem 



* Symbols defined in common deck 
•• Mutually exclusive fields; FET 
both fields. 



COMSPFM. 

may contain either but not 
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PERMANENT FILE TYPES 

There are two types of permanent files available to users of 
NOS: direct and indirect access files. 

• A direct access permanent file is read and 

written by user I/O requests just as any local 
file would be read or written. Large data 
files occupy large amounts of mass storage and 
are normally created as direct access files. 
(Direct access files are allocated by logical 
t racks . ) 



• An indirect access permanent file is accessed 

by using a working copy of the file rather than 
the file' itself; The working copy is attached 
as a local file to the user job. Thus, 
modifying the working copy does not alter the 
actual permanent file. Indirect access files 
are allocated in sectors and are generally used 
for small permanent files. 

A direct access permanent file is normally declared by the user 
prior to writing the file by using the DEFINE control statement 



or macro. The DEFINE may be issued 
written but, in this case, the file 
available to the user for permanent 
permanent files are declared by the 
statements or macros after the file 



after the file has been 
must reside on a device 
files. Indirect access 
SAVE or REPLACE control 
has been created. 



Whenever a permanent file is declared, the user index is mapped 
into a catalog track where permanent file names and statistics 
for that user are maintained. There is one catalog entry for 
every permanent file known to the system. A catalog track 
normally contains entries for several different users. A 
description of this mapping is provided in the NOS System 
Maintenance Reference Manual. 

A family consists of 1 to 63 mass storage devices. Within a 
family, each user has a master device that contains his permanent 
file catalogs, all of his indirect access files, and some or all 
of his direct access files. Again, the mapping of a user index 
into a master user within the family is shown in the NOS 
Installation Handbook. 

If more than one family is available in the system, the user 
must specify which family via the USER control statement. 
Although a family may have up to 63 devices, the number of mass 
storage devices in the configuration is still limited by 
installation parameter NMSD. 

A user may allow other users to access his permanent files with 
the PERMIT control statement or macro, which results in adding 
an entry to the permit chain. 

Direct access permanent files have the following characteristics. 
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• Allocated by logical tracks and, therefore, 
normally used for large files. 

• When accessed, all users interact with the 
same (only) copy of the file. 

• Write inter lock , 

• Multiread capability (multiple FNT/FST) 

• Created/accessed with DEFINE and ATTACH macros 
or control statements. 

• Fast attach capability. 

Indirect access files have the following characteristics. 

• Allocated by sectors and, therefore, normally 
used for smal I files. 

• When accessed, each user interacts with his own 
copy oft he file. 

• Created via SAVE or REPLACE macro or control 
statement. Accessed by OLD control statement 
or GET macro or control statement. 
Information can be added to an indirect access 
file with the APPEND control statement. 

For direct and indirect access files the user can specify one of 
the following permission modes for other users who access the 
files. 

Read 

Execute only 

Write 

Append 

Modi f y 

Null 

Read/modify 

Read/append 
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USER NUMBERS CONTAINING ASTERISKS 



User numbers that c 
automatic read-only permiss 



ontain asterisks represent users with 



ion to files in other user catalogs. 



all 



The user number must match the alternate user number in 
characters not containing asterisks 

For example, user number ABC* can access all the Permanent fi 
of ABCl! ABC2, ABCS, and any 4-character user number whose fi 
three characters are ABC 



f i les 
rst 



MASTER DEVICES 




determined number of catalog tracks. 



Fach master device has a prei . . 

The MS? word ALGL contains permanent file information in the 
following format. 



ALGL 



59 



47 



35 



23 



11 



1st track IAF 



label track 



permits track 



no. catalog 
tracks 



OAT track 




track. 
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If all the catalog tracks cannot be contiguous, then the next 
available tracks are used for the catalog, and in this case bit 
17 is not set in MST word PUGL. The first catalog track is 
pointed to by the TRT link from the label track position. 

Since each user is mapped to a particular catalog track, and 
these tracks are contiguous, the link byte in the last sector 
does not link to the next track in the chain. If this track 
becomes full, catalogs cannot overflow to the next contiguous 
track (other users are mapped to that track). A new track is 
linked into the chain via the TRT table, and the last sector 
link byte points to this new track. PFM then has increased the 
length of this catalog track. This slows PFM when it has to 
search more than one catalog track for any one user. So bit 16 
is set in PUGL and an is displayed in the E,M display to 
indicate catalog overflow. 

Many users can be mapped to any specific catalog track, but no 
user can be mapped to more than one catalog track (in case of 
overflow, it is considered a very long track). 

As a user creates permanent files, the entry shown in figure 14-1 
is placed in the appropriate catalog track and the file is 
processed by PFM. 



DIRECT ACCESS FILE PROCESSING 

Direct access files are processed as follows. If the file 
resides on a device in the user's family which can contain 
permanent files, the entry is created, the first track is 
recorded, and the first sector entry is set to 4000B denoting a 
direct access permanent file. Since this is a regular file, 
sector contains the system sector and sector 1 is the first 
sector of data. PFM issues the STBM function to set the 
preserved bit in the TRT. If the file does not reside on such a 
device, the job is aborted unless error processing was desired. 
In order to avoid this possibility, the user should define the 
file prior to writing on it. 

If the file does not exist, PFM creates the file on a device in 
the user's family that can contain permanent files. PFM also 
creates a catalog entry and builds the appropriate system sector 
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59 56 53 47 44 4 



word 




F i gure 1 4 



-1 . Permanent File Catalog Entry 
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file name 
user i nde x 
file lengt h 
track 
sector 



Permanent file name 

User index of file creator 

Length in PRUs of the file 

Beginning track of file 

Beginning sector of file (4xxx for a 
di rect access file) 



random index Random disk address of permit sector 

creation date Date and time (y ymmddhhmms s in octal) 
and time when this file was first entered on 

the permanent file system. The year 

( yy ) is bi ased by 70 . 

access count Count of accesses to file 



data modi f i- 
cat i on date 
and time 



ct 



Date and time (yymmddhhmmss in octal) 
when the data in this file was last 
modified. The year (yy) is biased by 
70. For direct access files this 
field is updated only when the file 
is attached in a modifiable mode. 

File category : * 

Symbol Desc ri pt ion 

FCPR Private 

F CSP Semi private 

FCPB Public 

Mode of access for semi-private and 
pub lie f i les : * 

Desc ri pt i on 

Write 

Read and/or execute 

Append 

Execute 

Negate previous 
permission 

PTMD Modify 

Figure 14-1. Permanent File Catalog Entry (Continued) 



mode 



Symbo I 


PTWR 


PTRD 


PTAP 


PTEX 


PTNU 



* Symbols defined in common deck COMSPFM. 
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ef 



ec 



PTRM 
PTRA 
Error flags: 
40 

Er ror code : 


1 
2 
3 
4 
5-7 



Read, allow modify 
Read, allow append 



File error when purged 
(error code in ec field) 



No error 

Error in file data 

Error in permit data 

Dat a/permi t errors 

EOI changed by recovery 

Rese rved 



dn 



last access 
date and 
time 



Device number CO through 77B); each 
device within a. family of permanent 
file devices is identified by a 
devi ce numbe r 

Date and time (yymmddhhmmss in octal) 
when this file was last accessed. 
The year (yy) is biased by 70. 



cont rol 
modification 



Date and time (yymmddhhmmss in octal) 
when the control information (catalog 
date and time entry and permit record data) for 
this file was last updated. The 
year (yy) is biased by 70. 



pr 

br 
ss 



Preferred residence. 

Backup resi dence . 

Subsystem code for this file: 

NULL subsystem 

1 BASIC subsystem 

2 FORTRAN subsystem 

3 FTNTS subsystem 

4 EXECUTE subsystem 

5 BATCH subsystem 

Figure 14-1. Permanent File Catalog Entry (Continued) 
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utility 
control date 
and time 



Date and time (yymmddhhmmss in octal) 
used to determine this file's 
candidacy for being dumped by 
permanent file utilities. The year 
(yy) i s bi ased by 70, 



file password Optional password 

user control User control information (FET+11) 
word 



Figure 1 4-1 . 



Permanent File Catalog Entry 
( Cont i nued) 



INDIRECT ACCESS FILE PROCESSING 

If the permanent file is an indirect access file/ then the entry 
is copied from the file that is to be made permanent; that is, 
indirect access files are allocated by PFM and the system does 
not keep track of them. The user must create the file first, 
and then issue the SAVE or REPLACE control statement. 



PFM 

rese 

p res 

byte 

kept 

and 

i ndi 

mast 

have 

for 

the 

cont 

Sect 



keeps 
rved 
e rved 
po 
to a 
cont r 
rect 
e r de 

all 
the f 
i ndi p 
a i ns 
or 3 



an 
from 

bi t 
i nt s 

mi n 
ac t e 
acce 
vice 
of h 
i le 
ect 
the 
cont 



i ndi rec 

t he sy 

is set 

to the 

imum le 

d (DTKM 

ss file 

since 
is indi 
i s as f 
access 
system 
ai ns da 



t ac 
stem 

to 

f i r 
ngt h 

or 

tra 
evey 
rect 
olio 
f i le 
sect 
ta f 



cess 

as a 

prese 

st t r 

when 

DLKM) 

ck ch 

user 

acce 

ws . 

chai 
or f o 
or th 



file track chain. This chain is 

normal file chain and the 
pve it over deadstapts. Word ALGL 
ack of this chain. The chain is 

possible, and is expanded (RTCM) 

as necessary. However, the 
ain must completely reside on its 

mapped to the master device must 
ss files on this device. The format 
Sector is the system sector of 
n and sector 1 is an EOI. Sector 2 
r the first indirect access file, 
e first indirect access file. 
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1 


n 




n+1 










track chain 
system 
sector 


eoi 


1st file 
system 
sector 


first 
file 


eoi 


2nd file 

system 

sector 


2nd 
file 


eoi 


• • • 

— — — — p. 



FILE CREATION, DELETION 

As each SAVE or REPLACE function is processed, the PFM indirect 
access file track chain gets n contiguous sectors (the Length of 
the user's file including the system sector) on the indirect 
access file chain. It copies the user's file including the 
system sector and the EOI. The number of sectors copied, not 
counting the EOI sector, is saved in the catalog entry as well as 
the first track and sector number of the file. Sector 4000B does 
not exist so there is no confusion between direct access and 
indirect access file entries in the catalog entries. 

As more files are saved and defined, the catalog entries grow 
and could cause overflow as described earlier. However, 
available slots in the catalog entries are created by purges of 
permanent files. These available slots are known as holes. 

When a direct access file is purged, the user index is set to 
zero, and all the tracks in that file chain are released to the 
system. These tracks can be used by the system for any purpose. 

When an indirect access file is purged, its user index is set to 
zero; however, the sector count field is left intact. The 
sectors are not released physically unless the file was so large 
it spanned one or more whole tracks. In which case the tracks 
are returned to the system (DLKM) and the sector count field is 
set to the remaining sectors. These sectors can only be used by 
new indirect access files. 

In the case of the REPLACE command, the following steps occur: 
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1. If the new file is the same size as the existing 
file, the new file is copied over the old 
indirect access file. 

2. If the new file is smaller than the existing 
file, the new file is copied over the old one, 
the sector count field is modified, and a new 
permanent file catalog entry is built. This 
entry has a user index of zero, sector count 
field set to the remaining sectors, and first 
track and sector pointing to the remainder of 
the old file (that is, a hole). This is not 
done if the hole size equals two sectors. 

3. If the new file is larger than the old file, the 
current entry becomes a hole (user index zero). 

A new hole is found if one big enough exists, or 
the new file is placed at the end of the 
indirect access files and a new catalog entry is 
used . 

Hole searching is accomplished the same way for SAVE and REPLACE 
commands. Only the catalog track (plus overflow tracks, if any) 
m a p ped to by the user index of the user are searched. All 
catalog tracks are never completely searched. The search 
proceeds as follows: 

1. If a hole with the exact number of sectors 
available is found, it is used. 

2. If not 1, then the largest hole larger than the 
f i le i s used . 

3. If not 1 or 2, then the file is put at the end 
of the indirect access files and a new entry is 
used . 

Eventually many holes result and a PFDUMP, INITIALIZE, and PFLOAD 
are required to close the holes. PFLOAD will recreate the 
catalog entries and indirect access files with no holes. 

ACCESSING FILES 

When a GET function is issued, PFM finds the entry, copies the 
file from the indirect access file to a local file (LOFT), and 
creates an FNT/FST entry for this local file with the proper 
permission bits set. PFM counts the sectors copi ed ' (exc lusi ve 
of the EOI) and compares them with the sector count field, and, 
if they do not agree, it issues a file length error. The same 
procedure is used for the OLD command, except the local file is 
of type PTFT. 
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When an ATTACH ' funct ion is issued, PFM finds the catalog entry 
and creates an FNT/FST pointing to this file. The file type is 
PMFT and the permission bits are set accordingly. 



If 



When an ATTACH function is issued by an SSJ= job, PFM first 
checks to see if a fast attach of the file can be performed, 
the SRNF special request (force non-fast attach) is not 
specified, PFM searches the system FNT/FST for an FAFT entry with 
the proper file name and family. If such a file is found, PFM 
bypasses the catalog search and permits checking and creates an 
FNT/FST (type PMFT) pointing to the file. 

CATALOG/PERMIT ENTRIES 

On all non-fast attach functions, PFM maps to the proper catalog 




semi-private or public files from all alternate user numbers. 
The original owner always has permission to use the file. 

For a private or semiprivate file, PFM first checks for an 
explicit permit. Byte 2 of word ALGL points to the first track 
of the permits track chain. The catalog entry for the file 
points to the first sector within the chain which contains 
permit entries for the file. Each of these entries indicates 
the permission mode available to a single user # number- If an 
explicit permit for the user is found, permission is granted 
according to the mode specified in the permit entry. 

For a public file, or a semiprivate file for which no 
appropriate explicit permit is found, permission is granted 
according to the mode specified in the catalog entry for the 
file. 

The format of the permit entry is as follows. 




used for 
linkage 



up to 31 permit 
entries (two 
words per entryj 
if more than 31, 
overflow to next 
sector) 



77 B 
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random index 



Disk address of next PERMIT buffer 
for this user index. Zero indicates 
end of chai n . 



user index 



User index who created this sector. 



access count The number of times the permitted 
user has accessed the file. 

mode Mode of permitted access (defined in 

COMSPFM; refer to catalog track entry 
described earlier in this section). 
If bit 41 is set, indicates 
accounting permit entry; if bit 41 is 
zero, indicates explicit permit entry 

access Time and date of last access by 

date and time permitted user. 

Table 14-1 illustrates the relationship between the requested 
access mode and the mode specified in the catalog or permit 
entry. A y entry indicates permission is allowed; n indicates 
permission is not allowed. 

TABLE 14-1. MODE RELATIONSHIPS 



Mode 






MODE 


IN CATALOG/PERMIT 






Requested 


PTWR 


PTRD 


PTAP 


PTEX 


PTNU 


PTMD 


PTRM 


PTRA 


PTWR 


y 


n 


n 


n 


n 


.0 


n 


n 


PTRD 


y 


y 


n 


n 


n 


y 


y 


y 


PTAP 


y 


n 


y 


n 


n 


y 


n 


n 


PTEX 


y 


y 


n 


n 


n 


y 


y 


y 


PTNU 


n 


n 


n 


y 


n 


n 


n 


n 


PTMD 


y 


n 


n 


n 


n 


y 


n 


n 


PTRM 


y 


n 


n 


n 


n 


y 


y 


n 


PTRA 


y 


n 


n 


n 


n 


y 


y 


y 



Table 14-2 illustrates the operations involved for each PFM 
function. 
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TABLE 14-2. PFM FUNCTIONS AND PROCESSES 



Ope rat ion 



PFM Function 



* 
SAVE 



GET 



PURGE 



CATLIST 



PERMIT 



Catalog search 
for hit 



Update PFC entry 



Catalog search 
for ID hole 



Update hole 



Catalog search 
for DA ho le 



Permit search 
for hit 



Update permit hit 



Permit search 
for ho le 



Update hole 



System sector 
update 



EOI update 



Catalog search 
to end 



Pe rmi t search 
to end 



BOI/EOI verify 



* Operations restricted to indirect access files 

X Always 

Not always 

U Direct access files only 
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TABLE 14-2. PFM FUNCTIONS AND PROCESSES (CONTINUED) 



| PFM Funct ion I 


I * I * I I I I 
Operation | REPLACE I APPEND | DEFINE | ATTACH | CHANGE | 


Catalog search | | | I I I 
for hit I X JX | X| X | X| 

Update PFC entryl X | X | | | X | 

Catalog sea rch | I I I I I 
for ID hole I X I X j | | I 

Update hole I X | X j | j j 

Cat a log search | I I I I I 
for DA hole | I I X j | | 

Pe rmi t sea rch | | | | I I 
for hit | j j j I I 

Update pe rmi t I I I i I I 
hit j | | j I I 

Pe rmi t sea rch | | | | I I 
for hole | I I I j j 

Update hole | I I I | | 

Sys t em s ect or I I I I I I 
update | j | X | X | # | 

EOI update I I I I I I 

Catalog search | | | | | 

to end j X j X | I | X | 

Permi t search | I I I I I 
to end || | | I I 

BOI/EOI verify | | | | | | 



* Operations restricted to indirect access files 
X A Iway s 

Not always 

# Direct access files only 



60454300 A 



14-16 



PFM STRUCTURE 

Routines called by PFM include the following: 
OAV User verification 
OBF Beginfile 
ODF Drop f i le 
ORF Update resource files 



F„ consists of a few resident subroutines and the followin 9 



P 

overlays: 



Ove r lay 



Descr i ptipn 



3PA 
3PB 



Command processor 

SAVE and REPLACE command processing 
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Overlay Description 

3PC APPEND command processing 

3PD ATTACH processing 

3PE Catalog list routines 

3PF DEFINE processing 

3PG PERMIT/PURGE processing 

3PH Error processing 

3PI Auxiliary routines 

3PJ CHANGE processing 

3PK Device-to-device transfer 

3PL APPEND, original file transfer 

3PM DEFINE auxiliary routines 

figure 14-1 shows the allocation of PPU memory for PFM overlays. 
There are six load addresses used for 3Px overlays. 



Load Addres s 



OVLA 



OVLC 



BFMS 



LOCG 



LOCI 



BUF 



Definition 

End of PFM resident. Used as load address 
for overlays not requiring common catalog/ 
permit manipulation routines in 3PA. 

End of general command processing 
subroutines in 3PA. Used as load address 
for command level overlays that require 
catalog/permit routines. 

SYSTEXT symbol used for auxiliary overlay 
load address and mass storage I/O. 

End of 3PA resident. Load address for 
overlays requiring termination processing 
in 3PA, but not ca t a log /pe rmi t routines. 

Maximum of BFMS and LOCF + ZDFL where LOCF 
is the address to load zero-level overlays 
in 3PA. Load address for auxiliary 
overlays that also need to call zero-level 
ove r lay s at LOC F . 

End of 3PK. Start of storage buffer for 
device-to-device transfer. 
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4K 
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6K 
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O 
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, PPFW 




GET command 
processing 


1 






PFM 1 

3PA 

3PB 

3PC 

3PD 

3PE 

3PF 

3PG 

3PH 

3PI 

3PJ 

3PK 

3PL 

3PM 


OVLA 


3 PA 






3PE 


4 


OVLC 
3PB , 


0VLC + 
OVLL 






3PC 






3PD 






3PF 






3PH 


... 4 






3PG , 






3PJ , 






LOCG 

1 3PK 1 




BFMS 




OVLC 




_» 


BUF 
H 3P M 

OVLA 


LOCI 
1 3PM 1 


4> 
1 





ROUTINE PFM 



PFM provides storage for the call block and other temporaries 
Its resident subroutines are as follows. 



Sub rout i ne 
SFA 
CCI 
DPP 
ERR 
SFN 
MSR 



Desc r i pt ion 
Set FET address 
Clear catalog interlock 
Drop PPU 
Process error 
Set file name in CM 
Mass storage read error processor 



PFM presets processing routines to: 

Verify FET parameters 

Verify user validation allowances 

Place request in recall if catalog is 
i nt er locked 

Issue accounting messages 

Load proper function processor overlay (3PA 
or 3PE) 

Call RESEX if pack is unavailable 



3PA - MAIN COMMAND PROCESSING 

Routine 3PA performs all processing required to perform the GET 
function. It performs preliminary processing for the following 
commands : 



SAVE 



APPEND 
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ATTACH 
GET 
PURGE 
PERMIT 



DEFINE 
CATLIST 
REPLACE 
CHANGE 



3PA also contains: 

• Catalog processing routines 

• PERMIT processing routines (some) 

• Fileallo cation routines 

• General subroutines 

The fol lowi ng out Line describes 3PA subroutines and buffers in 

more detail. Many of the 3PA subroutines are called from other 

3Px overlays. Those called from another overlay are labeled with 

an asterisk. Overlay 3PA resident routines include *TRP 

(terminate program). Resident common decks include *C0MPSNT (set next 

track) and *C0MPRNS (read next sector). Next , *L0CG , devi ce-t o-dev i ce 

transfer buffer, overlays subsequent subroutines. 

PERMIT subroutines include t he f o I lowi ng . 

Subroutine Description 

Create PERMIT entry 



CPE 
*CPI 
*UPI 
CSA 
SPI 
PPE 
WNP 
FPE 



Check permission information 
Update permission information 
Compute sector address 
Search permission information 
Process PERMIT read error 
Write new PERMIT buffer 
Form PERMIT entry in buffer 
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Catalog processing subroutines include the following. 

Sub rout i ne Desc r i pt i on 

*CCS Create catalog sector 

*DCE Delete catalog entry 

FCE Form catalog entry 

FHE Form ho le ent ry 

*UCE Update catalog entry 

*SSC Select catalog entry 

*SCH Search catalog 

PCE Catalog READ error processor 

CCD Check catalog data 



Allocation subroutines include: 

Sub rout i ne Desc r i pt i on 

AFS Allocate file space for indirect file 
ACS Allocate catalog space 
APS Allocate PERMIT space 



CML 



Check mass storage limits against 
validation limits 



General subroutines include: 

Subrout i ne Desc ri pt i on 
Drop tracks 



*DTK 
*ITC 
*ITF 
*CFA 
*RTK 
• WBI 



Interlock track chain 
Inter lock file 
Check fast attach f i le 
Request linked track 
Write buffer in p lace 
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Common decks include the following. 

Common Decks Description 

COMPCRA Convert random address 
•COMPSEI Search for end-of-i nf orma t ion 
•COMPCTI Clear track interlock 
•COMPSTI Set track interlock 
•COMPCKP Set checkpoint bit in EST entry 

OVLC command processing overlays are loaded next and destroy 
following subroutines. These overlays must not exceed VLL " 
OVLL is defined to be OVLC plus one full PRU plus one short PRU 
GET and ATTACH processing routine and the command processing 
initialization (SET) follow. 



Catalog search 

Subrout i ne 



*ISP 

*SPN. 

•COMPIRA 

•COMPFAT 

•COMPSAF 

•COMPSFB 



initialization subroutines include the following 
Desc r i pt i on 
Initialize search 
Set permanent file name 
Initialize random access processors 
Search for fast attach file 
Search for assigned file 
Set file busy 



3PA calls many of the other 3Px overlays. Those called are 
shown in table 14-3, 
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TABLE 14-3. OVERLAYS 3Px CALLED BY 3PA 



Ove r Lay | 
Name 


Load 
Address ! 


3PA Subroutine ! 
Ca L Led From | 


Command Processed 


3PI I 


BFMS 


ISP 






3PB 


OVLC 


SET 




SAVE/REPLACE 


3PJ 


OVLC 


SET 




CHANGE 


3PF 


OVLC 


SET 




DEFINE 


3PG 


OVLC 


SET 




PURGE/PERMIT 


3PD 


OVLC 


SET 




ATTACH 


3PC 


| OVLC 


SET 




APPEND 


3PK 


LOCG 


| GET 




| GET 



3PB - SAVE/REPLACE PROCESSING 

The 3PB overlay contains subroutines for processing the SAVE and 
REPLACE commands. It aLso contains the foLLowing subroutines. 

Subroutine Desc ri pt ion 

REP Process REPLACE command 

SAV Process SAVE command 

CUC Check user controLs 

PFR Process fiLe replacement 

SSP Set statistical parameters 

C FS Check file size 

Overlays 3PK and 3PI are called from 3PB. 
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3PC - APPEND PROCESSOR 

The 3PC overlay contains the .following subroutines for 
processing the APPEND command. 

Subroutine Description 

App Process APPEND command 

AFS Allocate file space 

CUC Check user controls 

SSP Set statistical parameters 

C FS Check file size 

Overlays 3PK, 3PI, and 3PL are called from 3PC. 

3PD - ATTACH PROCESSOR 

Overlay 3PD is called from subroutine GET in overlay 3PA to 
process the request to attach a direct access file to a job. 
3PD consists of the following subroutines. 

Subroutine Description 

Process ATTACH command main program 

Check file mode 

Clear local user table 

Check size limits 

Determine local user table to update 

Initialize mass storage 

Read system sector error processor 



ATT 
CFM 
CLU 
CSL 
DLT 
IMS 
MSS 



Common decks in 3PD include COMPRSS for reading system sectors 
and COMPWSS for writing system sectors. 
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3PE - CATALOG LIST ROUTINES 

Overlay 3PE is called from the preset subroutine, PRS, in the 
main program, PFM. Routine 3PE is loaded at OVLA and is called 
to read permanent file catalogs for a central processor program. 
Data is returned to the CM buffer specified by the FET pointers: 
FIRST, IN, OUT, and LIMIT. Refer to the CATLIST macro in volume 
2 of the NOS Reference Manual for a complete description of the 
use of the FET pointers for this function. 

Overlay 3PE consists of the following subroutines. 

Subrout i ne Pes c ri pt i on 

CAT Ma i n p rog ram 

NCS Normal catalog search (mode=0) 

ACS Alternate catalog search 

PDS PERMIT data search 

SBS Set status of FET (update IN) 

RBS Read buffer for search 

MSR Mass storage read error processor 

S H B Search catalog buffer 

WDB Write buffer 

CCP Check catalog permission (clear password) 

DFS 



SPB 
CSA 
C S U 
ISP 

Common decks include: 



Determine file size (store in catalog 
entry) 

PERMIT buffer search 

Compute sector address 

Check for special user 

Initialize search of catalog with common 
deck COMPSCA (set catalog address) 
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Common Deck 
COMPCRA 
COMPSRA 
COMPSEI 
COMPRNS 
COMPSDN 
COMPSCA 



Pes c r i pt i on 

Convert random address 

Set random address 

Search for end-of-i nf o rma t i on 

Read next sector 

Search for device number 

Set catalog address 



3PF - DEFINE PROCESSOR 



Overlay 3PF is called to create a direct access permanent file. 
The file exists prior to the DEFINE command, or the file may be 
created after the DEFINE command. File residency is determined 
3PF for the two situations as follows: 



i n 



• Local file exists. The local file is made 
permanent if the local file resides on a 
permanent file device to which the user has 
access (as determined by the secondary mask for 
the device); otherwise, the request is aborted. 
The dt field of the call block is ignored. If 
the local file resides on a removable device, 
that device's pack name must be the same as the 
pack name specified in the call block. 

• No local file. If the dt field is zero, the 
file is placed on the device with the most 
available space. If dt is speci f i ed, the file 
is placed (started) on the device of that type 
with the most available space. If np (number 
of PRUs) is specified, the file is placed on 
the device (type dt, if specified) with the 
most available space, provided that np PRUs are 
available. If np PRUs are not available, the 
request is aborted with the message PRUS 
REQUESTED UNAVAILABLE. 

Routine 3PF writes a system sector for the file to reflect the 
permanent file status of the file. The catalog entry is stored 
in the system sector as indicated in the format below. However, 
note that byte 2 of word 1 is updated to indicate the current 
access modes. The current access mode values are as follows: 
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7 Write 
3 Modify 
1 Append 
Read 

The format of the system sector is shown in section 2. 

Overlay 3PF consists of the following subroutines: 



Subrout i ne 
DEF 

cue 

PFE 
MSS 
DFR 
CPR 

DDN 
SFT 

sue 



Desc r i pt i on 

Main routine to build catalog entry and 
write system sector 

Check for maximum number of files reached 

Process f i le error 

System sector error processing 

Determine file residency 

Check for proper family or pack name 
residency 

Determine device name from MST entry 

Set FNT/FST information 

Set user counts in system sector 



Common decks include COMPRSS, COMPWSS and COMPWEI. 

3PG - PERMIT/PURGE PROCESSOR 

Overlay 3PG contains routines to process PERMIT and PURGE 
requests. 3PG consists of the following subroutines. 

Subroutine Description 

PUR Process PURGE request 

PER Process PERMIT request 
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Sub rout i ne 
DDF 
UEP 
USS 
MSS 



Description 
Delete direct access file 
Update existing permit entry 
Update system sector 
Read system sector error processing 



Common decks include COMPRSS (read system sector) and COMPWSS 
(write system sector). 

3PH - ERROR PROCESSING ROUTINES 

Overlay 3PH contains the error processing routines for all other 
overlays. It performs the following: 

• Sends the indicated error message to the 
day f i le . 

• Sets the FST entry not busy or deletes the 
FNT/FST entry if created by PFM. 

• Terminates the calling program if user error 
processing is not specified. 

• Drops the PPU. 

Overlay 3PH contains a list of error messages issued by PFM. 
These messages are listed in the NOS Reference Manual, volume 1. 
Some messages are sent to the control point dayfile while 
others are sent to the error log. 



3PI - AUXILIARY ROUTINES 

Overlay 3PI contains auxiliary routines used by many of the 
other 3Px overlays. These auxiliary routines can be overlayed 
after execution by any process that uses BFMS since 3PI is 
loaded at BFMS. Overlay 3PI contains subroutine search for 
system file (SSF). Currently, 3PI contains two common decks: 

COMPSCA Set catalog address 

COMPSDN Search for device number. 

3PI must not overflow into the error processor and therefore 
must be no more than one PRUin length. 
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3PJ - CHANGE PROCESSOR 

Overlay 3PJ processes the CHANGE command by changing and 
replacing the catalog entry for a file. 3PJ contains the 
following subroutines. 

Subrout i ne Desc r i pt i on 

CHG Process CHANGE request 

CCE Change catalog entry 

C FN Check f i le names 

PCE Catalog read error processor 

SCT Search cat a log 

S FL Set f i le names 

USS Update system sector 

MSS Read system sector error processor 

3PK - DEVICE-TO-DEVICE TRANSFER 

Overlay 3PK processes device-to-device transfers for those PFM 
operations that deal with indirect access permanent files. 
Overlay 3PK contains the following subroutines. 

Subrout ine Desc ript i on 

DTD Device-to-device transfer 

DPC Decrement PRU counter 

PTE Process transfer error 

IBA Increment buffer address 

SDP Swap disk parameters 

WES Write EOI sector 

WNS Write next sector 

CEI Create EOI sector 



3PL - APPEND - ORIGINAL FILE TRANSFER 

Overlay 3PL accomplishes the actual writing of the permanent 
file device with the appended permanent file. The order of 
transfer is old permanent to new permanent file, then the system 
(local) file to new permanent file. 
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Overlay. 3PL contains the subroutines APPEND disk transfer (ADT) 
and process APPEND error (PAE). 

The following common decks are included in 3PL. 

Common Deck Desc ript i on 

COMPCTI Clear track interlock 

COMPSTI Set track interlock 

COMPCKP Set checkpoint bit in EST 
Overlay 3PL is called only by overlay 3PC. 

3PM - DEFINE AUXILIARY ROUTINE 

Overlay 3PM contains subroutine DRF - determine file residency ■ 
which is used by overlay 3PF when processing the DEFINE command 
Overlay ODF is executed by 3PM. 
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TELEX TIME-SHARING SUBSYSTEM 



15 



INTRODUCTION 

TELEX is a subsystem that provides support for interactive 
processing from remote terminals such as TTYs (teletypewriter 
terminals) and CDC 713s. The subsystem consists of the following 
CPU and PP programs. 



P rog ram 
TELEX 



TELEX1 



TELEX2 



1TA 



1TD 



1 TO 



Description 

Time-sharing executive initialization routine. 
This routine is loaded at 40000B relative to 
control point 1 when the operator types TELEX. 
It initializes tables and pointers and loads 
TELEX1. 

Time-sharing executive processor. This is the 
main routine that processes I/O for the TTYs. It 
cracks and processes commands/ and makes requests 
to dump source input to disk and refill output 
buffers from disk. It communicates with the 
transaction facility (at another control point) 
to support transaction terminals. 

Time-sharing executive termination routine. This 
routine is executed after an abnormal condition 
is detected or when the operator terminates TELEX 
with 1 .STOP. 

TELEX auxiliary function processor. This routine 
processes functions for TELEX which require PP 
action. 

Terminal communications driver low-speed 
interactive (600 baud or less). It performs 
communications between TELEX and terminals 
(accessed via the 6671 and 6676 multiplexers). 
It also communicates between TELEX and the NOS 
stimulator ( chec kout / t es t ) . 

Terminal i nput / out put . Called by TELEX to 
perform terminal I/O requiring disk accesses. 



The relationship between the various system routines and 
subsystem routines is shown in figure 15-1. 
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terminal 



■;— (ny 



Terminal 

Communications 

Driver 




*MTAj TELEX Assistant 



wlTO) Terminal I/O 



Figure 15-1- TELEX Interactive Subsystem 
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TERMINAL OPERATION 

The flow of data to or from a terminal and a mass storage device 
is shown in figure 15-2. The terminal user enters source 
statements. These statements are built character by character 
and stored in pots (a pot is an eight-word- buff er) by 1TD. 
Whenever 1TD has filled VIPL pots (defined in common deck 
COMSREM) it issues a dump pot request. TELEX initiates the 
routine DMP (local to TELEX) which calls 1T0. In the interim 1TD 
may have filled another pot. Routine 1T0 dumps the accumulated 
pots onto one sector on mass storage. Thus, currently, during 
this phase 20 or 30 words are written per sector. 



TELEX 



f Terminal V »M TdV^ 




Figure 15-2. Terminal Mass Storage Data Flow 
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This continues until the user enters a command that forces a sort 
such as RUN or LIST. If the unsorted file is too Large, then the 
message FILE TOO L0N6 TO SORT is issued. In this case, the user 
must issue the SORT command. 

If, however, the file is not too long, then the terminal is 
placed in sort mode. An MTOT job called MSORT is scheduled and 
all users in sort mode are sorted at once. These users are 
queued up until a specified time interval has expired, then the 
MSORT job is run. All the files are given to MSORT in file size 
order, largest first. 

MSORT is an in-memory shell sort. It is started at a control 
point with the FL necessary to sort the largest file. It sorts 
the file and rewrites the file in packed format (that is, 1UU 
words per sector). When MSORT has finished a sort, it releases 
FL down to the necessary size for the next file and then sorts 
it. This continues until all the files are sorted. Routine 1 RO 
sets all he terminals whose files were sorted to active mode and 
TELEX then processes the command that indirectly caused the sort. 

TERMINAL JOB INITIATION 

Refer to figure 15-3 for this discussion. Assuming that a 
user's primary file has been sorted and RUN is entered at the 
terminal, the following events occur. 

1. TELEX builds a control statement CSLDC or compiler 
control statement) in a pot and calls 1TA. 

2. 1TA builds a rollin queue entry in the system FNT/FST 
area. The FNT entry points to the user's rollout file 
(refer to figure 15-21). 

3. The scheduler, 1SJ, determines that this is the best 

job to initiate, so it assigns a control point and calls 
1RI to roll in the job. 

4. 1RI reads the rollout file to build system FNT entries 
as specified, builds an FNT entry for the primary file 
(input to the compiler), and completes the 
initialization of the control point. 

5. 1RI then calls 1AJ to advance the job which detects the 
$LDC or compiler control statement and loads the 
compiler with sufficient field length to compile the 
source statements. ($LDC is used to load the BASIC 
compiler.) After compiling, the program is executed. As 
the job executes it may interact with the terminal by 
issuing output and receiving input. 
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TELEX builds a 
control card pot 



Read next 
control card 




FNT/FST 



TELEX 




1AJ K 
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Control 

Point 
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Rollin 
Queue 
Entry 




Rollout 
File FNT 
Entries 



Set up user control point 



Figure 15-3. Terminal Job Initiation 
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TERMINAL JOB INTERACTION - OUTPUT 

Refer to figure 15-4 for this discussion. When a terminal job 
writes information to the OUTPUT file, the following events 
occur. 

1. CIO is called when the interactive program issues a 
write request to the OUTPUT file. CIO senses that this 
is a time-sharing job (TXOT) and issues monitor 
function ROCM to roll out the control point. 

2. 1R0 initiates the rollout and copies the entire field 
length (including output data) to the rollout file. In 
addition, all FNT entries associated with this control 
point are removed from the system FNT area and stored 
on the rollout file. Prior to calling 1T0, 1R0 reads 
the first sector of output into 1R0's PP memory where 
it can be picked up by 1T0 without additional disk 

i nput /output . 

3. 1T0 is loaded into the same PP as 1R0. The monitor 
function TGPM assigns 1 TO pots into which it writes the 
output data. 1T0 then informs TELEX that output is 
available for the terminal by issuing monitor function 
TSEM. 

4. TELEX assigns the data pots to 1TD for transmission to 
the terminal. 1TD continues to ask TELEX for additional 
output and TELEX in turn calls 1T0 until all output has 
been t ransf e r red . 

5. After all output is transferred, TELEX calls 1TA to 
reinitiate the time-sharing job. 1TA builds the 
rollin file entry in the system FNT area. 

6. Scheduler 1SJ selects this queue entry as the best job, 
assigns a control point, and calls 1RI. 

7. 1 R I rolls the job into the control point and the 
time-sharing job continues to execute. 
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TERMINAL JOB INTERACTION - INPUT 

Refer to figure 15-5 for this discussion. Assuming that the 
time-sharing job is to receive data (input) from the terminal, 
the system performs the following functions. 

1. The job issues a read request on the INPUT file which 
calls CIO. CIO stores the FET address in control point 
area word TINW and issues monitor function ROCM to roll 
out the job. 

2. 1R0 is loaded to perform the rollout operation. 1R0 
flags the request in terminal table word VROT and then 
calls 1T0 to complete the process. 

3. 1T0 issues any available output and issues monitor 
function TSEM to inform TELEX of the completion of its 
processing. 

4. TELEX calls 1TD to send any output and/or issue the 
input prompt character (?). 

5. 1TD stores characters in pots as they are received from 
the termi na I . 

6. When the terminal carriage return is sensed, TELEX calls 
1TA to reinitiate the time-sharing job. 1TA builds a 

ro I li n queue ent ry . 

7. 1SJ selects the queue entry as the best job, assigns a 
control point, and calls 1RI. 

8. 1RI rolls the job into the control point and transfers 
the input data from the pots to the job's circular 
buffer. The job is then activated (given the CPU) and 
continues to execute. 
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Figure 15-4. Terminal Job Interaction (Output) 
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Figure 15-5. Terminal Job Interact i on .( INPUT) 
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TELEX INTERACTIVE JOB NAMES 

Whenever a job is initiated at a control point, 1TA generates a 
job name based on terminal number and user index of the user. 
The common deck COMPGJN (generate job name) is used for this 
task. Whenever a job is rolled back to TELEX by 1R0, the job 
name must be decoded back to the terminal number. Routine 1R0 
uses the common deck COMPGTN (generate terminal number) for this 
task. In this way, 1R0 knows the terminal table in which to 
indicate the rollout back to TELEX. The terminal number is coded 
into the fifth through seventh characters of the job name. The 
user index is coded into the first thru fourth characters. 



INTERACTIVE COMPASS PROGRAM EXAMPLE 

The following program demonstrates how an interactive COMPASS 
program could be structured. 



OUTPUT 

OUTBUF 

INPUT 

INBUF 

IN 

SETUP 

START 



IDENT INTER 

ENTRY START 

FILEC OUTBUF, 101 B,FET=6 

BSS 1 01 B 

FILEC INBUF, 1Q1B,FET=6 

BSS 101B 

BSS 16 

VFD 42/0L0UTPUT,18/0UTPUT 

SA1 SETUP SET FET POINTER FOR BUFFER 

FLUSHING 

BX6 X1 

SA6 2 

BX6 X6-X6 TERMINATE FILE LIST 

SA6 3 

WRITEC OUTPUT, ( = C* THIS PROGRAM INTERACTS.*) 

READ INPUT 

READC INPUT, IN 

WRITEC OUTPUT, IN 

WRITER OUTPUT 

ENDRUN 

END START 



The following demonstrates how the program is executed. 



old, 
READ 
bate 
SRFL 
/ com 

/ Igo 
THI 
? pi 
PLEA 
LGO. 



interf 
Y. 
h 

,0. 

pass,i = interf, 1 = 
1 .008 CPU SECONDS 

S PROGRAM INTERACTS, 
ease repeat after me 
SE REPEAT AFTER ME. . 



ASSEMBLY TIME 
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TELEX INITIALIZATION 

Basically, TELEX initializes tables and pointers, then loads and 
starts TELEX1, the main routine. PP programs called during 
initialization include the following. 



Program 



Desc ri pt i on 



CIO 
CPM 
LDR 
PFM 
1 MA 
1 TA 
1 TD 



Combined input/output 
Control point manager 
Load overlay 
Permanent file manager 
Issue dayfile message 
Auxiliary function processor 
Terminal multiplexer driver 



I 



When the operator types TELEX., DSD calls 1DS which generates an 
input FNT/FST entry of a special type. Routine 1SJ recognizes 
this entry during its scheduling process, assigns the entry to 
the proper control point, and calls 1 S I into a PP. Routine 1SI 
calls a procedure file named TELEX, an indirect access file 
found under the system user index. The recommended contents of 
this file are as follows. 

•RETURN PROCEDURE FILE TELEX 

RETURN, TELEX. 

WHILE, TRUE, LOOP. 

TELEX. 

T E L E X 2 . 

SKIP, LOOP. 

EXIT. 

TELEX2. 

ENDIF,L00P. 

ENDW,L00P. 

Initialization consists of allocating tables, establishing the 
pointers shown in figure 15-6 and the constants shown in table 
15-1. 
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59 



47 41 35 



RA + 3 



+ 4 




+ 5 



+6 



+ 7 



+ 10 



+ 11 



+ 12 



+ 13 



+ 14 



+ 15 



+ 16 



+ 17 




23 17 11 

71 



FWA terminal tables 




first network terminal number 



fwa message status table 



fwa network activity table 

T 7 




A 



LWA + 1 terminal tables 



last network 
terminal number 



lwa + 1 message 
activity table 



lwa + 1 network 
activity table 




VTTP 



VNTP 



VMST 



VNAT 



VPLP 



VCTP 



VBMP 



VWMP 



VRAP 



VPTP 



UTRN 



DBUG *1 



VFNL 



*1 Driver debug word. 

*2 Useful in debugging 1TD. 



Figure 15-6. Pointer Addresses 
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59 



RA + 20 



+ 21 



4-22 



+ 23 



+ 24 



+ 25 



+ 26 



+ 27 



+ 30 



+ 31 



47 23 



number of times had to wait for PP 



total users since initialization 



current active user count location 



maximum number of possible users 



new available pot count during FL change 



negative indicates no reload 



real-time clock at last recovery 



abnormal occurrence counter 





minimum number spare pots 



maximum number spare pots 



number of pots allocated (available) 



number of pots in use 



VPPL 



VTNL 



VANL 



VMNL 



VCPL 



VRLL 



VABL 



VPLL 



VPAL 



VPUL 



Figure 15-6. Pointer Addresses (Continued) 
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RA + 32 
+ 33 

+ 41 
+ 42 

+ 43 

+ 44 

+ 45 



+46 



59 


47 


23 


11 




v. 


monitor TSEM queue 






• 




v 



monitor TGPM queue 



end of monitor queue 



VTRP 



VTGP 



VTEQ 




VDRL 



Figure 15-6. Pointer Addresses (Continued) 
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TABLE 15-1. TELEX CONSTANTS 



Constant 



Value 



Description 



MSORFL 
VBFL 
VBPL 
VBPT 

VBTL 

VCPC 
VCPT 
VDSL 
VIPL 

VMPL 

VMTO 

VNPL 
VNTL 

VNTO 

VOPL 
VRBL 

VSBL 
VSPL 

VTGL 
VTRL 
VXPL 
UTIS 



4 

2 
3 

1 2B 

10 
1 

100 
2 

40 

10 

4 
13B 

20 

4 

1 1 / V C PC 

100/VCPC 
20 

VTEQ-VTGP 

VTGP-VTRP 

20B 

10 



MSORT base FL 

Default BATCH subsystem FL 
Maximum ABL for low-speed lines 
Additional PLT words per high-speed 
I i ne 

1T0 call time delay for high-speed 
lines Cone second) 
Number of words per pot 
TELEX control point number 
Length of driver circular queue 
Number of allowable source pots before 
dump 

Maximum number of spare pots per 64 
users 

Multiplexer terminal SALVARE file time- 
out value (minutes) 

Minimum number of pots for network 
Default 1T0 call time delay (two 
sec onds ) 

Network terminal SALVARE file time-out 
value (mi nut es ) 

Number of pots issued for multiplexer 
Transaction receive buffer length in 
pot s 

Transaction send buffer length in pots 
Minimum number of spare pots per 64 
users 

Length of monitor TGPM queue 
Length of monitor TSEM queue 
Maximum number of pots for network 
Default user time limit/10 
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TABLE 15-1. TELEX CONSTANTS 
( Cont i nued) 



Constant 



Va Lue 



Desc ri pt i on 



The fo 



L Lowi ng a re 



VROT status bits used with 1R0 



VJIR 

VRIR 

VIPR 

VOPR 

VECS 

MAXTT 

MPLT 

WCQT 

LIAA 
CBASE 

LISDL 
COMDL 
EXEDL 
CATDL 
SORDL 
BATDL 
RESDL 
SWPDL 
NULDI 
BASDI 
FTNDI 
TRADI 
EXEDI 
BATDI 
ACCDI 
SYSDI 
SALTO 



1S1 

1S2 

1S3 

1S4 

1S10 

1024 

120B 

100 

4 


2 

6 

5 

5 

2 

4 

4 



10 

4 

4 

4 

4 

5 

10 

3 

3 



Job in system 

Job to be rolled in again 

Input requested 

Output avai lab le 

Job uses ECS 

Maximum number of terminals 

Number of PLT words per 64 users 

Wait completion queue delay time 

(msec . ) 

Login attempts allowed 

Default base for command parameter 

(octal) 

List delay time 

Compi le delay time 

Execute delay time 

CATLIST delay time 

Sort de lay t i me 

Batch de lay time 

Resequence delay time 

Swap- in delay time 

Null input response delay time 

BASIC input response delay time 

FTNTS input response delay time 

Transaction input response delay time 

Execute input response delay time 

Batch input response delay time 

Access input response delay time 

System processed commands 

SALVARE file time check (mins.) 



The following illustrates the multiplexer table. An entry 
exists for each time-sharing multiplexer in the EST which is on 



MUXP 



59 


47 




35 


23 




11 


channel 


O 


number of ports 


O 


first port 



After initializing the tables, TELEX modifies addresses in 
TELEX1 code which use the increment instruction operation 
definitions. Next, each terminal table entry is set to complete 
status by setting VROT equal to 3 in each entry. Next, the 
warning message address VWMP is set to the normal header. Next, 
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TELEX calls 1TA to search for time-sharing jobs in the system. 
The jobs searched for are TXOT and MTOT type. The count of such 
jobs is returned in a pseudo terminal table for TELEX. If the 
count is nonzero, TELEX aborts with the message: TELEX 
INITIALIZATION ABORT. Next, each driver queue is initialized by 
setting FIRST, IN, OUT, and LIMIT. The driver queues are used 
like circular buffers. Finally, after starting the drivers and 
verifying the recovery file (SALVxx, where xx is the machine ID), 
TELEX is complete and control is transferred to TELEX1. 



TELEX1 - MAIN PROGRAM 

TELEX1 is the main program that controls and coordinates the 
time-sharing subsystem. This program is driven by the following 
queues . 



Request entering TELEX: 
Queue 



Desc ri pt i on 



Driver request Requests from 1TD 

Monitor request Requests from other PPs 

Monitor pot request Requests from other PPs for pots 



Internal cont ro I : 

Queue 

Wait comp let ion 
T i me de lay 
Job 

Sort 



Desc ri pt ion 

Wait for completion of a process 

Wait for time to elapse 

Wait to do all job scheduling at 

one time 

Wait to do all sort scheduling at 

one time 



Requests sent by TELEX: 

Queue 

1TA 
1T0 



Desc ri pt ion 

Send all 1TA requests at one time 
Send all 1T0 requests at one time 



These queues are scanned by the TELEX1 control loop which is 
defined in the flow chart of figure 15-7. 
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*1 The SALVARE file contains a two-word entry for each user in 
recovery state. 

Figure 15-7. TELEX1 Control Loop 
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Every 3 minutes the SALVARE file entries are checked and if the 
time is over 10 minutes old, the entry is removed, the rollout 
file and all nonpermanent local files are dropped, and the 
terminal logged off. The users must recover within 10 minutes of 
system recovery or the SALVARE file entry will be eliminated. The 
SALVARE file is discussed further under SALVARE - TELEX Recovery 
File in this section. 

The relationship between processing modules of TELEX1 is shown 

in figure 15-8. 




Control Loop 



PCS 



I 



Queue Processor 



Request Processing 
Routines 








Command 
Processor 












I 




V 








Subroutines 







Figure 15-8. TELEX1 Processing Modules 

In general, all tables in TELEX are dynamic in length at 
initialization time. The lengths of the various tables and 
queues are determined by the maximum number of terminals to be 
serviced. Thus, it is necessary for all routines at 
initialization time to determine the values of table pointers, 
and so on. Once TELEX is initialized, the lengths of tables do 
not change. Thus, pointers such as FIRST and LIMIT could be read 
and saved by programs that are time critical. These pointers 
could also be saved as abolute addresses because TELEX will never 
be moved. Thus, no SYSEDITs which change ,the size of CMR can be 
run while TELEX is running. The TELEX1 memory layout is shown in 
figure 15-9. 
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TELEX1 { 



RA 


Table, queue, and buffer 
pointers set at initialization 


RA+77B 


Statistics 


VTRP 


TSEM and TGPM queues 


RA+MUXP 


Multiplexer tables 


TRQT 


Queue table 


PCOM 


Subsystem table 




M 


///////////////// 

'////, Subroutines ///// 


m 


TCOM 


Command table 




W/. 


'////, Subroutines ///// 

v//// /////////// 


W/. 


TRRT 


Reentry control table 




WZ 


/////^Subroutines ///// 

V/////////////// 


w. 


PBUF, 
SBUF 


Command parameter buffer 




% 


///////////////// 

////^Subroutines///// 

V//////////////A 


IP 


VDRL 


Driver request queue 




Character translation tables 


VTTP 


Terminal table 


VRAP 


Reentry table 


VPTP 


Transaction word table 


VPLP 


Pot link table 


VBMP 


Pots 
(8 -word buffers) 


RA+FL 





EXIBUF = load address 
for TELEX2 (the exit 
processor) 



-Coded routines 



Figure 15-9. TELEX1 Memory Map 
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DRIVER REQUEST QUEUE(S) 

Driver (1TD) requests are passed to TELEX1 via the driver 
request queue which are circular stacks as shown in figure 15—10 



FIRST 




LIMIT 



T 



driver request queue entries 
(one word each) 



, 100B 
words 



Figure 15-10. Driver Request Queue Stack 



Driver request queue entries are placed in a circular stack by 
1TD. The IN pointer is updated by 1TD when an entry is placed 
into the queue. TELEX1 updates the OUT pointer as the driver 
requests are completed. The driver name is stored in word 1 
with a pointer to the next stack. A zero pointer indicates the 
last stack. Each stack is 105B words in length (100B words for 
entries plus five header words). A maximum of four stacks may 
exist; one for each driver (1TD). The entries are one word as 
f o I lows : 



59 


47 




35 




23 




11 







2000+rq 





P2 


Pi 




tn 





rq Request number 

p2 Parameter 2 

p1 Parameter 1 

tn Terminal number 
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The request number is always biased by 2000B so that a jump 
table index can be stored in a B register with use of the unpack 
instruction. For example, if the above word is in X2, consider 
the following instruction. 

UX1,B7 X2 

The result is that B7 contains the request number and X1 
contains the parameters and terminal number (that is, the lower 
48 bits). A list of request numbers (request codes) is 
maintained in common deck COMSTDR and are listed in table 15-2. 

TABLE 15-2. DRIVER REQUEST NUMBERS (ISSUED TO TELEX) 



Request 
Code 



Symbo I 



Description 




1 
3 

4 

5 

6 

7 

10 

11 

12 

13 

14 

15 
16 
17 
20 

21 
22 

23 
24 



AOD 
CSC 
CLI 

DLO 
DRP 
DRT 
HUP 
IAM 
LOF 
LPT 

MAL 

MTN 

RES 
RIN 
SAI 
SKY 

SPT 
SSC 

TTI 
EMO 



Increment 
Circuit s 
Command I 
P2= word 
Data lost 
Drop pot 
Drop pot 
User hung 
Issue ace 
Log off u 
Request a 
pot 

Set t rans 
P1 =s t atus 
Terminate 
t e le t ypew 
Request m 
Re lease s 
Set autoi 
Int e rrupt 
leve L 
Set t rans 
Set t rans 
P1 =code 
Tr ansae t i 
Comp let ed 



ret ry count 
can comp le te 

ine input, P1=first pot, 
i n pot 
, P2=type 

chain, P1=first pot 

up phone 
ounting message, P2=type 
ser 
dditional pot, P1=current 

action terminal malfunction, 
(1 =ma If unct i on, 0=none) 
monitor mode (monitor 

rit.er) 

ore output, Pl=current pot 

ource line, P1=first pot 

nput mode 
from terminal, P2=i nt er rupt 

action output pot, Pl=pot 
action sequence code, 

on terminal i nput 
marked transaction output 
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MONITOR REQUEST QUEUE(S) 

PP requests for TELEX processing are handled via the PP monitor 
function TSEM. The message buffer is set up by the requesting 
PP according to the following format. 



59 


47 




35 




23 




11 







2000 + fn 


Pi 


P2 


P3 


p4 



p1 - p4 Parameters depending on the function. 

fn Function code. These function codes are defined 
in packed format in common deck COMSREM. They 
are listed in table 15-3. 

TABLE 15-3. TSEM MONITOR REQUEST FUNCTIONS 



Va lue 



Name 



Desc ri pt ion 



2000 
2001 
2002 
2003 
2004 
2005 
2006 
2007 



VDP0 
VAS0 
VMSG 
VSDT 
VCDT 
VSCS 
VPTY 
VSBS 



Drop pot s 

Assign output 

Terminal message 

Set terminal table bit CVSTT only> 

Clear terminal table bit -CVSTT only> 

Set character set mode 

Set parity 

Set subsystem 



PP monitor picks up the above request and stores it in a free 
slot in the TELEX monitor queue for TSEM functions. This queue 
is located at VTRP in TELEX and is 10B words in length. If no 
slot is free in this queue, monitor (MTR) keeps trying until 
TELEX honors an existing request and clears a slot. 

In general, TELEX drops any unused pots in the chain. If the 
last pot is not completely filled by the routine issuing output, 
the routine must put in a terminator byte (0014) at the end of 
the output data. 

NOTE 

When issuing a 2001, terminal status must have 
bit 4 set in VR0T. 

Pots for output are obtained by issuing the monitor function 
TGPM. These requests are handled by TELEX in a three-word queue 
similar to TSEM requests. 
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The parameters for the various functions are defined as follows 



VDPO - Drop Pots (TELEX Routine DRT) 
59 47 35 23 



11 



2000 





yyyy 


xxxx 


nnnn 



yyyy 

xxxx 
n nnn 



Last pot to be dropped 
First pot to be dropped 
Te rmi na I numbe r 



VASO - Assign Output (TELEX Routine ASQ) 



59 



47 



35 



23 



11 



2001 





yyyy 


xxxx 


nnnn 



yyyy 

xxxx 
nnnn 



Last pot of output 
First pot of output 
Terminal number 



VSCS - Set Character Set Mode (TELEX Routine SCS) 



59 




47 




35 




23 




11 







2005 





yyyy 


xxxx 


nnnn 



yyyy 

xxxx 
nnnn 



Last pot containing mode 
First pot containing mode 
Te rmi na I numbe r 
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VPTY - Set Parity (TELEX Routine PTY) 



59 




47 




35 




23 




11 







2006 





yyyy 


xxxx 


nnnn 



yyyy 

xxxx 
nnnn 



Last pot containing parity 
First pot containing parity 
Te rmi na L number 



VSBS - Set Subsystem (TELEX Routine SBS) 



59 




47 




35 




23 




11 







2007 





yyyy 


xxxx 


nnnn 



yyyy 

xxxx 
nnnn 



Last pot containing subsystem 
First pot containing subsystem 
Te rm i na I number 



VMSG - Assign Message (TELEX Routine DSD) 



59 




47 




35 




23 




11 







2002 





yyyy 


xxxx 


nnnn 



yyyy 

xxxx 
nnnn 



Last pot of message 

First pot of message 

Terminal number; if below maximum number of 

pseudo terminals, then this is a warning message 

sent to all terminals 



VMSG is used by DSD to process 
commands . 



the DIAL and WARN operator 
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VSDT and VCDT TSEM Requests 



When 
that 
di sab 
in se 
gener 
appro 
t e rm i 
this 
The e 
speci 
tab Le 
comp L 



a terminal user initiates a CPU program, he may terminate 
program with the S or STOP entry. If the user wishes to 
le/enable this function he can use the DISTC macro described 
ction 12 of the NOS Reference Manual, volume 2. This macro 
ates an RA+1 call to the PP routine TLX. TLX issues the 
priate TSEM request (function 2003 or 2004), which sets the 
nal interrupt address in TIAW. The disable function ignores 
field and sets the disable bit in the terminal table VSTT. 
nable function sets this field to the address relative to RA 
fied in the call and clear the disable bit in the terminal 

VSTT. Refer to volume 2 of the reference manual for a 
ete description of DISTC. 



TGPM Request 

Pots for output are obtained by issuing the monitor function TGPM 
The requests are handled by TELEX in a 3-word queue similar to 
TSEM requests. The call to TGPM is as follows. 



OR 



59 



TGPM 



47 







Upon return, the OR is as follows 
OR 



59 




47 




35 










P 






p Pot pointer (0 if no pots available) 

If p^O, the PP should reissue the request. 

Whenever a PP needs a pot chain it issues the TGPM MTR request. 
MTR searches the TELEX TGPM queue for a nonzero entry. If MTR 
finds one, it will be the first pot of a pot chain. The chain 
size is an assembly constant and is currently fixed at 4 pots. 
This pot chain is assigned to the calling PP and the queue entry 
is zeroed. If the queue is empty, MTR issues an RCLM on TELEX. 

During TELEX's main loop it checks the TGPM queue and if it 
finds any empty entries, it generates a pot chain and places the 
first pot number in the queue. 

The TGPM is used by 1T0, which requests pots for flushing a TX0T 
type jobs OUTPUT file. Another user is DSD, who must get a pot 
chain for the WARN and DIAL messages. 
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TERMINAL TABLE 

The terminal table contains an eight-word entry for each 
possible active user. Each entry contains the current status of 
each port on each multiplexer. These eight-word entries are 
structured in such a way so as to minimize interlocks between 
TELEX1 and the various PP routines which read and write them. 

Word (VUIT) is written by TELEX and 1TA and read by TELEX and 
1TA. Its format is as follows. 



59 



17 



user number 



user index 



Word 1 (VFNT) IS WRITTEN BY TELEX, 1R0, and 1TA and read by 1RI, 
1TA, TELEX, 1R0, and 1TD. Its format is as follows. 



59 



17 



11 



primary file name 



mode 



bfl 



mode 
bfl 



Write lockout if bit set; execute only if bit 
2 set 

RFL value for batch subsystem; sector count for 
1 TA on RUN,- I=lfn 



Word 2 (VFST) is written by TELEX, 1R0, 1TA, 1RI, and 1T0 and is 
read by TELEX, 1R0, 1TA, 1RI, and 1T0. Its format is as follows 



59 



53 



47 



35 



23 



11 



eq 
list 



ea 
est 
ord. 



1st track 
primary 



current 
track 



current 
sector 



Word 3 (VROT) is written by TELEX, 1R0, 1T0, 1RI, and 1TA and is 
read by TELEX, 1R0, 1RI, 1TA, 1T0, and 1TD for the rollout file. 
Its format is as follows: 



59 



53 



47 



word 
cnt. 



est 

rollout 

file 



1st track 
rollout 



35 



field 
length 



23 



11 



substatus 



status 
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a Absolute FL flag; if not set, then FL is in units of 
100B 

subs tatus : 

File List if (list with EOR and EOF if 1) 

J ob status : 

Meaning Bit 



Level number 

SRU limit 

Time limit 

Terminate special job 

with FL 
Terminate special job 
Interrupt 
Input status 

EOI 

EOF 

EOR 



23-20 


19 


18 


17 


16 


15 


14 


13 


12 



status : 

TELEX in control 

System i n cont rol 

Job in system 

J ob to be rol led i n 

J ob awai t ing i nput 

Output ava i lab le 

TAFTS output bit 

Speci al system j ob 

Li st 

Mu It i-t ermi na I 

Suspended 

Not used 

Error on last operation 



Bit 



Va lue 






1 








1 





2 


1 


3 


1 


4 


1 


4 


1 


5 


1 


6 


1 


7 


1 


9 


1 


10 




11 


1 



Words, VDPT, VCHT, and VDCT are used by 1TD to maintain current 
information for the terminal. The main loop of 1TD reads these 
words into PP memory at direct cells DP, CH, and DC 
corresponding to VDPT, VCHT, and VDCT. When the main loop jumps 
to the appropriate routines, they use these direct cells instead 
of reading from CM. When control is returned to the main loop, 
it writes these direct cells back to CM if necessary. VDCT is 
mainly used for communication with TELEX and is interlocked by 
TELEX. If byte 4 is not clear, then this terminal is being 
processed by 1TD. When byte 4 clears, then 1TD is done and TELEX 
can use the information to continue activity for this terminal. 
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Word 4 (VOPT) is written by 1TD and read by TELEX1 and 1TD 
format is as f o L Lows : 

59 47 35 23 11 



Its 



first 


current 


posit 


flags 


addr 



first 
cur rent 
pos i t 



First pot of input Line 

Current pot of Line being processed 

Position within pot as foLLows: 



Bits 

1 1-9 

8 

7 

6-4 

3-0 



Meani ng 
First word in. first pot of input Line 
Input initiated 
Next input pot requested 
Current word in current pot 
Character number in current word 



fLags Control flags as follows: 

Bits Meani ng 

11-7 Translation table index 

6 Full duplex 

5 Polled terminal error flag 

Correspondence upper case flag 

4 Monitor mode 

3 Binary transmission 

2 Transparent i nput 

1 Extended mode transmission 

Odd pari t y 

addr The address of the PP driver subroutine which is 
currently processing the terminal 



Word 5 (VCHT) is read and written by TTD 
follows: 



Its format is as 



59 



buff 



47 



35 



23 



char 



scr 



11 



inp 



out 



buff 



char 



scr 



During input, buffer holds the upper (even) 
character of byte until the next character is 
received at which time both characters (one byte) 
are stored into a pot; during output, buffer 
contains the driver subroutine address 

Total character count of line being processed 

Scratch and reentry address for polled terminals 
(TAF/TS type); it most often contains the current 
input or output character for non-polled terminals 
(may also hold control byte during output) 
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i np 
out 



Total number of characters received from terminal 
Total number of characters transmitted to terminal 



Word 6 (VDCT) is written and read by TELEX1 and 1TD. Its format 
is as f o I lows . 



59 



47 



35 



23 



11 



flags 


term 


num 


ace 


next 



flags Flags as follows: 
Bit Value Meani ng 






0001 


1 


0002 


2 


0004 


3 


0010 


4 


0020 


5 


0040 


6 


0100 


7 


0200 


8 


0400 


9 


1000 


10 


2000 


11 


4000 



term 



Tape mode 
Auto mode 
Text mode 
Extended mode 
Transaction mode 
Monitor mode 
Read data mode 

Input requested 

User logged in 

Interrupt complete 

Driver request from TELEX1 byte 4 



Terminal control information as follows: 



Bit Value 



0-2 
7-3 
9-8 



0-7 

0-37B 

0-1 



11-10 



num 



ace 



next 



Mean i ng 

First word of output line in pot 
User defined carriage return delay 
Line type 

0-1 Terminal type 

2 Ha rdwi red li ne 

3 Po I led I ine 
Not used 



In AUTO mode, the line number increment; 

in MONITOR mode, the terminal number of the 

terminal being monitored (that is, the monitoree) 

Access control flags (lower 12 bits of access word 
defined in VALIDUs file for this user). Refer to 
the N0S System Maintenance Reference Manual for 
procedures to establish the access word. Refer to 
section 20 for a complete description. 

First pot of an output message assignment or 
driver request function code (byte 0, bit 59 
flag). (Refer to BGI - STT Subroutines). 
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Word 7 (VSTT) is written by TELEX and is read by TELEX, 1TA, 1TD, 
1T0, 1RI, 1R0, and DSD. Its format is as follows. 



59 


47 


35 


23 


11 


flags 


first 


cmand 


sys 


pot 



flags Flags as follows: 

Bit Value Meani ng 



48 


0001 


49 


0002 


50 


0004 


51 


0010 


52 


0020 


53 


0040 


54 


0100 


55 


0200 


56 


0400 


57 


1000 


58 


2000 


59 


4000 



first 



cmand 



sys 



pot 



Log-out in progress 

Unconditional abort flag 

Wa mi ng i ssued 

Run complete message 

Sort flag 

Not used 

J ob comp lete flag 

Input lost or job not started 

Not used 

Charge number required 

Conditional abort flag 

Disable terminal control 



First pot of source line input. This byte, along 

with byte 2 (pot count), is used in subroutine DMP 

to dump pots to disk as input is received by calling 
1T0. 

Pot count or index into command table, TC0M. The 
index is set by subroutine SCT. Also may be used as 
DSD command pointer. 

Bits 23-15 nonzero if files lost on RECOVER command. 
Bits 14-12 are current system in control: 



Null 
BASIC 



FTNTS 

Execute 

Batch 



6 Access 

7 Transaction 



Pot pointer to a queued output message. That is, if 
a message is already in VDCT and not yet processed, 
the next message is queued by using byte 4 of VSTT. 
If another message must be assigned, it will be lost 
Refer to subroutine ASM. Normally, this byte is 
zero. 
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Table 15-4 is a summary of the terminal table entry. 
TABLE 15-4. TERMINAL TABLE ENTRY SUMMARY 



Name 



Word | Written by 



Read by 



VUIT 
VFNT 

VFST 

VROT 

VDPT 
VCHT 
VDCT 
VSTT 



TELEX, 
TELEX, 



1TA 

1R0, 1TA 



TELEX, 1RI, 
1TA, 1T0 

TELEX, 1RI, 
1T0, 1TA 

1TD 

1TD 

TELEX, 1TD 

TELEX 



1R0, 
1R0, 



TELEX, 1TA 

TELEX, 1RI, 1R0, 1TA, 

1TD 
TELEX, 1RI, 1R0, 1T0, 

1TA 
TELEX, 1RI, 1R0, 1T0, 

1TA, 1TD 
TELEX, 1TD 
1TD 

TELEX, 1TD 
TELEX, 1RI, 1R0, 1TA, 

1TD, 1T0, DSD 



In table 15-4, the name TELEX refers to any of the three overlays 
comprising TELEX. Any routine which writes a word also is 
assumed to read that word. 



TRANSACTION WORD TABLE 

The transaction word table provides TELEX and TAF/TS 
communication and is pointed to by VPTP and contains the 
following one-word entry for each transaction terminal. 



59 




47 


35 


23 


11 


retry 
count . 


status 
flags 


output 
pot chain 


message 
sequence 


terminal 
address 



status f lags 

Symbol 

UTOB 
UTMB 
UAMB 
UWOB 



Bi t Meani ng 

47 Te rmi nal off 

46 Terminal malfunction 

45 Terminal waiting for message 

44 Terminal waiting for output 
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Byte 4 contains reservation flags in the following format 



11 



OOO 000 001 111 

A AAA 



' — pot in byte 3 reserved; 0= free pot 

1 pot in byte 2 reserved; 0= free pot 

— pot in byte 1 reserved; 0=free pot 

— pot in byte reserved; 0= free pot 



Each byte (0-3) represents a pot, an 8-word CM buffer starting 
at VBMP, Bytes 0-3 contain a link to the next pot in the chain. 
The last pot in the chain is indicated by a zero byte. Pot zero 
is always reserved and links to 7777. Each PLT byte has the 
f o I lowi ng f o rmat . 



11 




21 





word link 


i 


i 













1 — byte link 
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These words are written by TELEX transaction routines and read by 
the dri ve r, 1 TD . 

POT LINK TABLE 

The pot link table (PLT) controls the use of pots (8-word 
buffers). Its layout is as follows. 



VPLP+O 



+ 1 



+ 2 



byte 



byte 1 



byte 2 



byte 3 



byte 4 



7777 


0002 


1 


0003 


2 


0004 3 


0017 


0005 4 


0000 


5 


0007 


6 


0000 7 


0017 


0000 10 


0012 


11 


0013 


12 


0014 13 


0007 


■» 












•i 



In the preceding table, pots 1-5 are reserved and comprise one 
chain. Pots 6 and 7 comprise another chain. Pot 10 is free. 
Pot 11 is the start of another chain. 
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INTERNAL QUEUES (TRQT) 

All internal queues are built at assembly time in a table of 
queues. This table consists of all the queues that may have 
requests in the reentry table. The following is a list of 
valid queue names in the table of queues. 



Name 



Desc ri pt i on 



WCMQ 
TIMQ 



Wait completion queue 
Time delay queue 



JOBQ 
SORQ 
ITAQ 
ITOQ 



Job queue 

Sort queue 

1TA queue (PP request queue) 

1T0 queue (PP request queue) 



The PP request queues are one-word entries in the table of 
queues, while the other 4 are two-word entries. The format of 
the entries is as follows. 



59 




41 


35 




23 




11 







PPP 





fc 


tn 




PP 





ppp 1TA, 1T0 

fc Function code 

tn Terminal number 

pp Pot pointer 



59 




47 




35 


29 




17 


11 







2ccc 





nnnn 





yyyy 


C 


) 






ft. 


. t 









ccc Number of entries (packed format) 

nnnn First terminal entry (index into reentry table) 

yyyy Last terminal entry (index into reentry table) 

tt...t Resource control count 



NOTE 

Each queue has an associated string of 
entries in the reentry table. 
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REENTRY TABLE (VRAP) 

The TELEX subroutines use the reentry table to have control 

returned or functions performed for them when a set of 

conditions are met. The table consists of one word for each 
terminal with one of the following formats. 

59 



No reentry conditions 
59 47 



23 



11 



2yyy 


xxxxxxxx 


PPPP 


nnnn 



yyy Index to TRRT (table of reentry processors) 
xxxxxxxx Anything 

pppp Pot pointer for further parameters 
nnnn Link to next entry in the queue of this type (see 
TSR) 



59 


17 





nnnnnn 



nnnnnn 



Pot address of stacked entries 



Each entry in the reentry table contains 
of reentry routine parameters (TRRT). 



an index to the table 



TABLE OF REENTRY ROUTINE PARAMETERS (TRRT) 

This table is built at assembly time. It consists of entries 
that direct further processing based on entries from the reentry 
table and on completion of certain sections. Entries are added 
to the table by use of the COMMND macro. Entries are one word, 
according to the following format. 



TRRT 



59 


53 


47 




35 




17 







XX 


yy 


zzzz 


eeeeee 


nnnnnn 



X X 



yy 

zzzz 

eeeeee 

nnnnnn 



Index to TRQT (queue table); if xx=0, no 

resources are required except for a peripheral 

processor, possibly 

Function code for called program 

Function processing address relative to TSRPROC 

Error return address 

Normal return address 
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The COMMND macro format is as follows. 



LOCATION 



OPERATION 



COMMND 



VARIABLE SUBFIELDS 



pr oc , sy sr , npr o , erra , tunc 



p roc 

sy s r 

npro 
erra 

func 



Entry point of routine to process this command 

( zzzz) 

The queue that the request is to be placed in: 

WCMQ, TIMQ, JOBQ, SORQ, ITAQ, or ITOQ Cxx) 

Normal return address (nnnnnn) 

Error return address (eeeeee) 

Function code to be passed to the called program 

Cyy) 



The following example uses the COMMND macro to generate a queue 
entry. 

COMMND INP6,WCMQ,INP6,INP6 
INP6$ EQU * (This is generated by the COMMND 

mac ro) . 

INP6$ is rhe symbol for this word in the table of reentry 
rout i nes . 

Now to make the WCMQ queue entry: 



SX5 

EQ 



INP6$ SPECIFY COMMAND TABLE ENTRY 
PCS4 MAKE QUEUE ENTRY 



INP6 BSS 



NORMAL AND ERROR RETURN ADDRESS 



In general, queue entries are made in this manner throughout 
TELEX. 

^Figure 15-11 shows the relationship between the table of queues, 
the reentry table, and the table of reentry routine parameters. 
There is one queue entry per terminal. 
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word 1 of WCMQ from TRQT 



VRAP 



terminal 1 



terminal 2 



terminal n-1 



terminal n 



TRRT 



59 




47 




35 






17 













H 


?///, 


first 




last 








2005 






count of entries 








V 




I 






^ 





59 



47 



TRRT index 



TRRT index 



TRRT index 



TRRT index 



Reentry Table 



23 



11 



parameters 



parameters 



pot pointer 



pot pointer 



parameters 



parameters 



pot pointer 



pot pointer 







link 



link 



D 



link 






59 


1 


53 


47 


35 


17 


TRQT 
index 


func. 
code 


function 

processing 

address 


error return 
address (code) 


normal return 
address (code) 



set up by 

COMMND 

macro 



Figure 15-11. Table Relationships 
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QUEUE PROCESSING 

Processing of queue entries is done by the PCS subroutine. As 
entries are completed, PCS extracts the normal or error return 
address and jumps to it. Making queue entries is done by a jump 
to PCS4 or PCS6. Before returning to a routine, PCS calls SSP 
which sets up the following registers (from the queue entry, 
bits as shown) . 



Register 

AO 
B2 
B3 

B4 
X7 



Description 

FWA of user's, terminal table entry 

Terminal number (bits 11-0) 

Pot pointer (extracted from byte 3 of entry 

in reentry table) (bits 47-24) 

FWA of pot pointed to by B3 (B3*10+VBMP) 

Bits 47-24 of reentry table entry 



These A 
va ri ous 



and B registers are generally not changed within the 
subroutines of TELEX. 
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TELEX ROUTINES 

The following is an outline of the subroutines comprising TELEX 

• MUXP - Multiplexer table (RA + 101B) 

• TRQT - Table of queues: 



STR 



CSF 
DRI 



PCM 



WCMQ 


ITAQ 


TIMQ 


ITOQ 


JOBQ 


PFMQ 


SORQ 





TEL - Control loop; calls the following: 



CSF 
CTB 
DRI 
EPP 



PPU 
RPC 
SCH 
SOR 



SPR 
STM 
STR 
TDQ 



TSR 
URT 



- Process requests to handle output to terminal by 
calling the following subroutines: 



ASO 
CDT 
DRT 



DSD 
PTY 
SBS 



SCS 
SDT 



- Checks SALVARE file user time out 

- Process driver (1TD) requests by calling the 
following subroutines: 



AOD 
CSC 
CLI 
DIN 



DLO 
DRP 
DRT 
EMO 



HUP 
IAM 
LOF 
LPT 



MAL 
MTN 
RES 
RIN 



SAI 
SKY 
SPT 
SSC 



TTI 



- Process terminal commands (called from CLI, AUT); 
calls following subroutines: 



ACC 


DIA 


LIS 


REP 


SUB 


ASC 


EDI 


MTR 


PER 


TAP 


ATT 


FDP 


NOR 


ROT 


TER 


AUT 


GET 


NOD 


RUN 


TXT 


BAT 


HEL 


NOS 


SAV 


UNS 


BIN 


HDP 


PAC 


SOF 


UNU 


BYE 


LAN 


PAR 


STA 


XEQ 


CLR 


LEN 


PFC 


STO 





Reentrant command processing routines 



BJB 
BJS 
EJB 
IDT 



IEX 
INJ 
IPF 
IPL 



IUA 
PBS 
PSS 
DAF 



IAF 
PFF 
PFM 
PFP 



PUR 
RDY 



• PCS - Process queue entries 

• PPU - Process PP requests 
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RPC - Ref i I L pot chains 

SCH - Build job queue entry for scheduling a job 

SOR - Set up for scheduling SORT job 

SPR - Call 1TA to adjust field length 

TDQ - Process time - delay queue 

TSR - Process WCMQ; reenter the following: 

DCR ITA MJE SRE 

HNG ITO MTO SSO 

ICH JOB REC 

INP LIN SEN 

General subroutines including: 



ABT 


CPF 


GPL 


MQE 


SFL 


BRQ 


DAP 


GQE 


MVA 


SLF 


CCM 


DMP 


GRT 


06S 


SRC 


CFL 


DPT 


GTA 


PCB 


SRR 


CJT 


ENP 


GZP 


RPL 


SSP 


CLE 


GEM 


ISH 


RPT 


TPF 


COI 


GFN 


LTT 


SAF 


UPF 


COP 


GFS 


MDA 


SCT 


UQS 



• Transaction routines including: 

Transaction executive driver routines 
Transaction executive interface routine 
General subroutines 

TELEX2 - TERMINATION OVERLAY 

TELEX2 performs exit processing for the TELEX subsystem. It is 
loaded whenever an abnormal condition is detected or when the 
operator types 1.ST0P to drop the subsystem. 

When an abnormal condition is detected within TELEX1 processing, 
a jump to the abort subroutine (ABT) is executed. ABT issues 
the message 

TELEX ABNORMAL - xxx. 

where xxx is the name of the subroutine calling ABT. 

After issuing this message, if sense switch 3 is on, the ABORT 
macro is used to abort the control point. Routine 1AJ senses the 
EXIT control statement, the next control statement (TELEX2) is 
found, and 1 AJ has the termination routine loaded. TELEX2 is 
loaded in a buffer which dumps the FL if requested and loads 
TELEX3 which leaves the tables and queues untouched. Basically, 
TELEX2 logs out all active users so that there will not be any 
time-sharing jobs left in the system. After issuing system 
statistics, 1TD is called to restart the time-sharing subsystem 
depending upon sense switch settings. (There are 6 sense switch 
options for TELEX. Refer to the NOS Operator's Guide for more 
information.) 
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MULTIPLEXER DRIVER 

Routine 1TD performs communication between TELEX and terminals 
(accessed via the 6671 and 6676 multiplexers) and the NOS 
stimulator. It has the capability to communicate with most ASCII 
compatible terminals and correspondence code compatible terminals 
such as the IBM 2741, NOVAR 541, and CDC 713 terminals, if the 
multiplexer has the required options installed. 

Routine 1TD processes up to 512 (10 character per second) 
terminals. The number of terminals for which performance can be 
guaranteed will decrease as the terminal speed is increased. In 
any event, the total driver capability is 5120 characters per 
second. The maximum terminal speed which may be accommodated is 
60 characters per second. 

Terminal communication is processed in a half-duplex mode. A 
line is generally the unit of transmission in each direction. 
Interruption of continuous output is provided along with an 
input line and character deletion facility. 

Communication between 1TD and TELEX is accomplished by means of a 
circular request queue provided by TELEX. Routine 1TD inserts a 
request in the queue and TELEX removes the request as it is 
p rocessed . 

Terminal control operations for ASCII terminals include the 
f o I lowi ng . 

• Complete an input line by pressing the return key. A 
line feed is not needed, since the driver issues one to 

the terminal. 

• Delete or ignore an input line by pressing the ESC key. 

• Delete a previously entered character by pressing the 
underline (back arrow on some Model 33 teletypewriters, 
backspace on the CDC 713). 

• Terminate output by pressing the BREAK key, or the S key. 

• Interrupt output by pressing the I key. Output may be 
resumed by pressing P followed by return. 

Terminal control operations for correspondence code terminals 
i nc lude : 

• Complete an input line by pressing the return key. 

• Delete or ignore an input line by pressing the ATTN key 

• Delete the previously entered character by pressing back 
space . 

• Terminate output by pressing the ATTN key. 
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Routine 1TD consists of routines 1TD and 2TD. Routine 1TD is 
the initialization (and termination) routine that Loads the 2TD 
overlay. The 2TD overlay is normally loaded and executing in 
the PP while the TELEX subsystem is servicing terminals. 
Several other overlays are assembled with 1TD. These are the 
translation tables for the various terminals listed in table 
15-5. 

TABLE 15-5. TRANSLATION TABLES OVERLAYS 



Overlay 



Te rmi na I Type 



9J A 
9JC 
9J E 
9JG 
9J I 



ASCII termi na I, 64 CS 

Correspondence/text, 64 CS 

Co r respondence/ APL, 64 CS 

Memorex 1240/APL, 64 CS 

ASCII block edit terminal, 64 CS 



Figure 15-12 shows the multiplexer servicing concept as being 
similar to the hardware slot and barrel concept for peripheral 
processors. Up to, eight multiplexers are serviced by the driver 
and each port is allotted a time slice in which the driver 
peforms I/O and required overhead. 
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Port 63 



Execution Slot 



Port 1 



Figure 15-12. Multiplexer Servicing Concept 
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DRIVER INITIALIZATION C1TD) 

The multiplexer driver is initialized by the overlay 1TD. This 
overlay consists of the following USE blocks. 



Block 

MAIN 

PRESET 

RESIDENT 



Desc ri pt i o n 

Initialize TELEX control point 

Load 2TD 

Code resident during execution 



The lengths of these blocks are determined by the difference 
between" thei r last word address and. their first word address as 
shown in table 1 5-6 . 



TABLE 15-6. USE BLOCK LENGTHS 



Last 
MANE 
RESE 
PRSE 



First 
MANF 
RESF 
PRSF 



Description 
Length of MAIN 
Length of RESIDENT 
Length of PRESET 



These three lengths are added and the sum is subtracted from 
4096 to establish the origination (ORG) address. The 
multiplexer input buffer (IBUF) is defined in PRESET and must 
follow the PP resident translation tables. A check for this 
overflow condition is made at the end of the 2TD overlay. 

Overlay 1TD is loaded when the operator types TELEX to start the 
time-sharing executive and during termination to perform certain 
post processing operations. Routine 1TD is called by 2TD from 
the DRP subroutine. Since 1TD is loaded above the translation 
tables, much of 2TD is overlayed when it calls 1TD. Routines 
overlayed include some write mode processing (WTM), all polled 
line processing routines, and all of the utility subroutines. 
In addition, the translation tables and the multiplexer input 
buffer are overlayed. Figure 15-13 shows the relative load 
addresses of the USE blocks comprising 1TD, as well as the 2TD 
overlay while executing. 
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2TD during execution 


MANF 

PRSF 
RESF 

7777 


1TD loaded 












100 


output buffers 


1077 
1100 


main loop 




MGR 
RWC 




RDM 




main 

comprsi 


» — . 




WTM 




PTP 




utility subroutines 




translation tables 




PRESET 








input buffer 


COMPMRQ 


7777 


resident code 


RESIDENT 



Figure 15-13. 1TD/2TD Memory Maps 
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Figure 15-14 provides an overview of 
processes in blocks MAIN and PRESET. 
2TD during termination processing. 



the initialization 
Resident code is used by 



Data in the multiplexer input and output buffers within 2TD 
consists of an 8-bit character per port along with control bits 
as shown in figure 15-15. 



60454300 A 



15-47 



main 




GET 



clear 

equipment 

tables 



IDS 



initialize 
control point 



LCT 



initialize drive 
stack address 



STA 



set translation 
table addresses 



set other 
table addresses 



allocate TAF/TS 
buffer if needed 



TCP 



terminate 
control point 



set first 
TELEX 
terminal number 



preset start 

address for 

each terminal 
in DP +4 



(pRSj P^et 



RPP 



load 2TD 



relocate ail 

addresses to 

absolute 



load PP resident 
translation tables 



clear output 
buffers 




enter 

AVTBJmain 

loop 



RA+100 
RA+1077 



Figure 15-14. MAIN and PRESET Overview 
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11 10 



Input from 6676 MUX 

7 6 5 4 3 
1 I 



data character - 
J I L 



t t t t 

I— Charact 



er reject - MUX would not send character to 
terminal; 1TD repeats output 



TTY on-line 



- Data lost -new character sent before old character 
accepted; 1TD is getting behind 



L- Valid character 



output to 6676 MUX 



11 


10 


9 


8 


7 


6 


5 4 3 2 


1 

















I i i 




^ 


4 




■ data chuiuclsi 

■ i _i 







bit 11=1 If valid character 



bit 11 = 1 
bit 10= 1 



Turn TTY off 



Figure 15-15. Input/Output Buffers 



Figure 15-16 describes the Logical breakdown of the 2TD driver 
whi Le executing. 
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Address 

77 
0BUF=100 

1077 
PPFW = 1100 



EXI1-EXI8 
MGR 
RWC 



loaded 
with 
1TD 
overlay 



TINT 
TOPT 

IBUF 



direct cells 



8 output buffers 



main loop 

service next MUX 

and stimulator 



reentrant routine return 



MGR -terminal manager 
RWC-read/write control 



read mode 
MUX-^pots 



write mode 
pots-* MUX 



polled line 
processing 



utility subroutines 
and exit processing 



translation tables 



input/output 
9J(x) 



input buffer 
100B words 



resident code 

COMPMRQ 

RPP 

tables: 

TEQN 
TNTD 
TTTC 
TITA 
TOTA 



Qualifier 



v 1TD 



} 1TD 



Figure 15-16. 2TD Memory Map 
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REENTRANT ROUTINE RETURNS 

The reenrant routine returns are eight entry points which are 
jumped to by any subroutine that cannot complete its function in 
a single time slice. The RETURN macro is the most common method 
used throughout the routine for the purpose of setting a return 
address. Control is returned to the next instruction or to 
another specified routine address. For example, 

RETURN EXI7 

enables control to be returned at the next instruction, while 

RETURN EXI3,LIN 

causes control to be set to the LIN sub rout i ne for the next time 
slice for this port. In any case, the EXlCx) specifies a 
reentrant return address. If x is odd, the reentry address is 
in the A register and stored in DP + 4 (that is, VDPT, byte 4). 
If x is even, no return address is given, and control is 
returned to the previous return address in DP+4. The reentrant 
return addresses and terminal table words updated are shown in 
table 15-7. 



TABLE 15-7 



ADDRESSES AND WORDS 



Reent rant 
Return Addres s 



EXI1, EXI2 

EXI3, EXI4 

EXI5, EXI6 

EXI7, EXI8 



Terminal Table Word(s) 
Written 



VDPT 

VDPT, VCHT 

VDPT, VCHT, VDCT 

VDPT, clear byte in output 
buffer 



Direct cell assignments are explained in the program. During 
execution VDPT, VCHT, and VDCT are available in direct cells. 
VDCT is read and updated only when necessary to minimize CM 
reads and writes. 

The main loop controls the advancement to the next multiplexer, 
performs multiplexer I/O, checks for stimulator processing, and 
enters the manager (MGR subroutine). 



PROCESS SUBROUTINES 

The MGR subroutine processes individual ports and satisfies 
requests from TELEX. A flowchart of MGR is shown in figure 
15-17. The symbol qualifier CTL contains the following routines 
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Rout i ne 



MGR 


CIS 


INT 


CTO 


DIN 


HUP 


OFL 


RWC 


DTT 


LIN 


RAB 


1 TD 


TFR 


Routine 



*1 



Description 

Te rmi na L manager 

Check interrupt status 

Process i nte rrupt 

Check time out 

Di a l-i n process i ng 

Hang up phone 

Process user off Line 

Read/Write control 

Determine terminal type 

Process logi n 

Read answerback drum 

Function codes for the processor TFR *2 

Process TELEX functions with the following 

sub rout i nes : 

Oescr iptio n 



BGI 
CFD 

HUP 
IIP 
LGI 
SNM 
SOP 
SEP 
SFD 
STT 



Beg in input 

Clear full duplex flag in VDPT 

values for byte 4 of VDCT. 

Hang up phone 

Issue input prompt (question mark) 

Process login 

Set normal modes 

Set odd parity 

Set even parity 

Set f u I I duplex f lag 

Set termi na I type 



1 TD f unct i on 



*1 VDPT word, DP+4 gets one of these addresses. 
*2 TELEX requests 1TD to perform certain functions by setting 
bit 11 of byte of VDPT and the function code in byte 4. 
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The symbol qualifier RDM contains the following read mode 
subrout i nes : 



Rout i ne 

BRD 
CRD 
ARD 



Desc ri pt i on 

Bi nary read 

Correspondence read (APL type, NOVAR) 

ASCII read 



These routines call RTC which translates the input character and 
stores it i n a pot . 

If the input character is a special character, one of the 
following subroutines is called. 



Rout i ne 



Desc r i pt i on 



CES 
CRT 
DLN 
DPC 
NLI 
CSF 
NWL 
EOT 
BRK 
ECI 
CAN 
EOL 
ETX 



Check escape status 

Process carriage return 

Li ne de let e 

Delete previous character 

Null i nput 

Case shift 

New line 

End of transmission 

Break 

Escape 

Cance I 

End of 

End of 



character input 
line block 
line (b lock edit) 
t e x.t 



CRT, BRK, CAN, and NWL call EIL for end of line processing which 
calls CLI for command line input and SLI for source line input. 

CLI calls ACL for ASCII end of command line or CCL for 
correspondence end of command line. SLI calls ASL for ASCII end 
of source line or CSL for correspondence end of source line. 

General subroutines used by RDM are as follows. 

Desc ri pt i on 

Issue terminal message 

No input pot available 

Process lost data 

Translate input character 

Write input character 

Process null i nput 

New line (unit for EOT from terminal) 

Normal read mode processing starts with the RDM subroutine which 
sets the return address in DP+4 to BRD, CRD, or ARD. As 
characters are received from the multiplexer, they are processed 
by RTC which calls TIC to translate them and then calls WIC to 
write them in pots. The normal exit is to EXI4. Figure 15-18 
shows the general relationship of the read mode processing 
sub rout i nes . 



Rout i ne 


ITM 


NIP 


DLO 


TIC 


WIC 


NLI 


NWL 
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The symbol qualifier WTM contains the subroutines used for write 
processing. These subroutines are structured similar to RDM 
subroutines and include the following. 

Routine Description 



BWT 
CWT 
AWT 



Binary write 
Correspondence write 
ASCII write 



These subroutines call WTC to write the terminal character by 
using the following subroutines. 



Rout i ne 

ROC 
TOC 



?_ e scr "'P t i on 

Read output character from pot 
Translate character 



A special character is processed by one of the following 
rout i nes . 



D escriptio n 

Null output 

ASCII terminal new line 

ASCII terminal carriage return 

Correspondence end of line 

Correspondence carriage return 

Correspondence line feed 

Correspondence backspace 

Other write mode general subroutines include the following 



Routine 


NLO 


ANL 


ACR 


CNL 


CCR 


CLF 


CBS 



Routine 

CMM 
SOC 
SRC 



Desc ri pt i o n 

Process monitor mode 

Set output cont ro I 

Send repeated character 



SOC restarts a job to get more output and processes output 
control bytes by jumping to one of the subroutines listed in 
table 15-8. 



60454300 A 



15-54 



MGR 



pick up 
next terminal 




pick up input 
from MUX 





read 
VDPT/VCHT 




(A) = input 
from MUX 



enter reentrant 
routine (DP+4) 



(VDPT ■ byte 4) 



process off-line 



Figure 15-17. MGR Flowchart 
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WIGR6J 

_L_ 

read VDPT 





no /MGR 
+\ 7 



check for 
interrupt 



read VCHT 




MGR4 



Figure 15-17. MGR Flowchart (Continued) 
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ESC 




CRT 






DLN 




DPC 




NLI 




CSF 




NWL 


// ( CLI ) 


EOT 


BRK 





EIL 



ALC 



CCL 



RWC 



ASL 



ARD 



CSL 



CRD 



*1 A Line with two headed arrows represents a subroutine 
entered via RJM instruction 



Figure 15-18. Read Mode Processing Subroutines 
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TABLE 15-8. CONTROL SUBROUTINES 



Cont roL 
Byte 



Subroutine 
Name 



Funct ion 



0000 
0001 
0002 
0003 
0004 
0005 



EOL 
EOB 
ECB 
ATI 
LOF 
TPI 



0006 


I BNI 


0007 


I BNO 


0010 


| ETM 


0011 


| BEO 


0012 


I MTO 


0013 


j EOS 



End of Line 

End of block 

End of correspondence block 

AUTO input 

Log off user 

Set transparent input (allows all 

characters to be transmitted to the 

CPU program) 

Set binary input 

Begin binary output 

End of transaction message 

Begin extended output 

End o marked transaction output 

End of string 



The relationship between the write mode subroutine is shown in 
figure 15-19. 



set (CH) = write processor 




1 


r 


(bwt 


EOB 


n 

-Wrwc J 


ATI 


LOF 


TPI 


BNI 




Br 


NJU 





WTC 



WTCX 



WTC 



*1 A line with two arrows indicate a return jump. 

Figure 15-19. Write Mode Processing Subroutines 
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Rout i ne 


SPL 


RPR 


PTR 


SSC 



The symbol qualifier PTP contains the routines used to process 
polled lines. These include the following. 

Description 

Sense po I led I i nes 
Read poll response 
Process terminal response 
Set sequence count 

Utility subroutines are under the symbol qualifier 1TD and are 
general subroutines used by the other routines described 
previously. The utility subroutines are as follows. 

Description 

Back up pointers 

Clean up terminal tables 

Put entry in TELEX's request queue 

Read VDCT ent ry 

Read link table to get next pot in chain 

Read previous character in pot 

Set control address (for instance, RDM uses 

this to set + read routine BRD, CRD, or ARD 

depending upon translation table) 

Wait time out 

Set address of current word of current pot 

Translate characters 

Exit processing routines include MXE to process multiplexer 
errors and DRP to process driver exit (call resident code set up 
by 1TD at initialization time). 

1TA TELEX AUXILIARY ROUTINE 

Routine 1TA processes functions for TELEX which require PP 
action. The functions allowed are listed in table 15-9. 

TABLE 15-9. PROCESS FUNCTIONS 



Rout i ne 


BUP 


CUT 


ERQ 


RDC 


RLT 


RPC 


SCA 


WTO 


SWA 


TCH 



Ove r lay 
Name 



Funct i on 
Code 



Rout i ne 
Name 



Desc ri p t i on 



3TA 
3TB 
3TC 
3TD 
3TE 
3TF 
3TG 
3TH 
3TI 
3TJ 
3TK 



1 

2 

3 

4 

5 

6 

7 

10 

11 

12 

13 



TFL 
RTJ 
CRF 
TLP 
DAM 
TRP 
IRL 
RFP 
SJS 
GST 
CUS 



JAdjust TELEX field length 
JReturn terminal job 
| C reate ro I lout file 
JTerminal logout processor 
JDisplay accounting message 
iTerminal recovery processor 
jlncrement resource limit 
|Recovery file processor 
|Sort and job scheduler 
j Gather stat i st i cs 
IClear up SALVARE file 
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TELEX calls 1TA in one of two ways. 



GROUP REQUEST 



A group of requests are stored in pots. The input register format 
is as f o I lows . 



59 


47 


41 


35 


29 


23 


11 







1TA 


cp 





return 


pot 


IR + O 


IR+1 


IR+2 


IR+3 


IR+4 



return 

cp 
pot 



Upper 24 bits of the word specified are set 
to zero upon completion of all requests. 
Control point number 
Pot containing the list of requests 



The requests are one word each with the following format: 



59 




35 




23 




11 







unused 


fc 


tn 


org 



f c 
tn 
a rg 



Function code 

Terminal number 

Pot pointer or request type 



The list of requests is terminated with a zero word. 



SINGLE REQUEST 

A single request is denoted by setting bit 35 in the input 
register which is formatted as follows. 



59 




47 


41 


35 


23 


11 







1TA 


cp 


4000B + fc 


tn 


org 


IR+O 


IR + 1 


IR+2 


IR + 3 


IR+4 



60454300 A 



15-60 



cp 
f c 

tn 
arg 



Control point number 

Function code 

Terminal number 

Pot pointer or parameter (depending on 

f unct ion) 



Routine 1TA uses several bits in 
These bits are: 



VROT of the terminal table 



Bit 



4 
10 
1 1 



Description 

Completion status bit 

Set to indicate recall function by TELEX 

Purge rol lout FNT* s 

Error return 



Figure 15-20 is the flowchart of the initialization, execution, 
and termination of the control loop for 1TA. 
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1TA initialization 
INI 



error exit 




set completion 

address 
(IR+2,3) ITAE 



store pot 

pointer 

(IR+4) ITAA 



SPA 



get pot 
address 



store pot 

address in 

ITAB 





<T) 



clear single 
request flag 
bit 35 of I R 



set ITAX to 

drop PP after 

completing request 





set error and 
completion bit 
in VROT for 
this terminal 




Figure 15-20. 1TA Control Loop 
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get next request (1TA) 




process function request 



increment to 

next request 

in pot 




store processor 
address and 
name ITAD 



no 




no 



yes 



set error exit 
ERX+1 ITAD 



-*UTA7J 
STA 



set terminal 
table address 



read 

VFNT-FN 
VFST-FS 
VROT — CN 



process 

function 

LJM (ITAD) 



Figure 15-20. 1TA Control Loop (Continued) 
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Function 5 is used to create a rollout file for a time-sharing 
job. The format of the rollout file is given in figure 15-21. 



system sector data 

dayfile buffer pointers 

INPUT file FNT/FST 

assigned equipment 

terminal table entry 



control point area 



dayfile buffer 



FNT/FST entries 



terminal output 



job field length 



system 
' sector 



Figure 15-21. Time-sharing Job Rollout File 
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1T0 " TTY INPUT/OUTPUT ROUTINE 

Routine 1TO is called ->y TELEX to process a queue of requests 
for terminal input and output which require disk accesses. The 
queue resides in pots within the TELEX field length. The queue 
has been sorted by TELEX in order of equipment and disk 
addresses so as to minimize disk time. If there are requests 
for more than one mass storage device, the entries are processed 
for the first device available. 

Routine 1T0 is also called by 1 RO to handle the first section of 
data on a rollout file. This data is passed to 1T0 in a PP 
buffer. Routine 1T0 dumps the PP buffer into pots and makes a 
VASO request to TELEX for that terminal. 

The input register format when 1T0 is called by 1R0 as follows. 



IR 



59 



41 



35 



23 



11 







1TO 


cp 





///// z/y^ 


tn 



cp 
tn 



TELEX control point number 
Te rmi na I numbe r 



The input register when called by TELEX is as follows 



IR 



59 



41 35 



23 17 







1T0 


cp 


PP 





return 



cp 
PP 

return 



TELEX control point 

POT pointer to first POT of requests 

Location of completion status word 



The request in POTs are one word entries with the following 
format. 



59 


53 


47 




35 


32 


26 


23 




11 







re 


eq 


track 


w 





X 


fp 


tn 
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r c 



eq 
track 



x 

fp 
tn 



Request code 

Correction dump 

1 Output data 
Equi pment numbe r 

First track of file if re = 0; 
cur rent track if re = 1 
Number of words in Last pot (0 
w is meaningful when re = 
Number of pots to dump; re = 
First pot of source or output 
Te rmi na I numbe r 



means 10); 



As a group of requests is 
updated by setting byte 2 
assigned. These requests 
f rom wh i ch they came . 



completed, the above entries are 
to the last pot to be dropped or 
then written back in the same 



are 



pot 



The flowcharts of 1T0 (figure 15-22) shows that it is broken 
down logicaly into the following sections. 



Preset or initialization 

Main loop (get next request) 

ICH subroutines (correction handler if re - 0) 

PRO subroutines to process output if re = 1 (that is 

data flow is disk to pots to terminal) 
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1T0 Initialization - PRS 




set terminal 

number (IR+4) 

TN PRCB+4 



STA 



set terminal 
table address 




1 


' 


Read 

VFST-FS 
VROT-CN 
VSTT — CM 



ypRsv 



read one pot 

of requests 

into EBUF 



UPP 



get next pot 
address 




Figure 15-Z2. 1TO I/O Routine 
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Figure 15-22. 1T0 I/O Routine (Continued) 
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SLB 



set sector 
linkage bytes 



DPB 



dump buffer 
to disk 



WEI 



write 

EOI 

sector 



FTN 



drop channel 



no 



FTN 



hang pp 



set last 
sector 
written 



FTN 



drop track 



update 

terminal 

table 



return 



) 



Figure 15-22. 1TO I/O Routine (Continued) 
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Figure 15-22. 1T0 I/O Routine (Continued) 
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Figure 15-22. 1T0 I/O Routine (Continued) 
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Figure 15-22. 1T0 I/O Routine (Continued) 
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ADDITIONAL CONSIDER ATI ONS 

The NETWORK or SIMFILE file specifies all the known terminals. 
Routine 1TD assumes all terminals are 110 baud (10 cps) 
time-sharing terminal type during login. 

The $LDC issued by TELEX is a compiler call statement issued i-n 
response to terminal user typing RUN or some similar call in the 
BASIC subsystem. 

The TT entry in VALIDUs is used for validation. If the entry is 
set, the user must be on that type of device to be validated. 
The TERMINAL table defines what type of terminal is calling. 



SALVARE-TELEX RECOVERY FILE 

The SALVARE file is a fast attach permanent file built by ISF 
during an initial deadstart or recovered during a recovery 
deadstart. The size of the file is determined by ISF and its 
length is not altered by TELEX. ISF assures that the file 
length does not exceed one logical track on the residence device. 

During initialization, TELEX reads the SALVARE file in 
subroutine URT to update the recovery times. This is done to 
assure that a user is given the full time to recover, no matter 
how long a system recovery has taken. 

During operation in TELEX1, the main loop calls CSF. CSF issues 
a 1TA queue call to check the SALVARE file in 1TA routine CUS 
function 20. CUS clears all entries in the SALVARE file and 
logs off users over 10 minutes old. This call is made about evey 
3 m i nu t es . 

Routine 1TA is a combination of functions to perform for TELEX. 
The important functions associated with the SALVARE are as 
follows. 



Function 

CUS 
TLP 
TRP 

RFP 



Description 

Clean up file 

Terminal log out processor 

Terminal recovery processor; this 

overlay contains the SALVARE format 

document at i on 

Recovery file processor 
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Since the SALVARE file is checked about every 3 minutes and 
entries more than 10 minutes old are eliminated, then: 

• A user that wishes to be recovered after losing contact 
must attempt recovery within 10 minutes. 

• Entries in the SALVARE file are updated upon system 
recovery so that a user is assured of the full time-out 
period after system recovery. 

Recovery is accomplished in the recovery file processor routine, 
RFP. The call to overlay RFP is as follows. 



IR 



59 



41 



35 



1TA 



23 



11 



I5B 



tn 



pot 



Upon entry, IR+4 contains the parameter pot number. The pot 
contains the terminal table. IR+4 is set to the previous 
terminal number, which is recovered from parameter pot . 



IR 



59 




41 


35 




23 




11 







1TA 





I5B 


tnn 


tnb 



tnn 
tnb 



Terminal number now 
Terminal number before 



To recover a user, the entry on the SALVARE file is found and 
the information is returned to the terminal table. The entry in 
the SALVARE file is cleared and the current rollout file is 
released. A dayfile message is issued indicating the user 
recove red . 

A completion logout is done for all entries that have been there 
longer than 10 minutes. At that time the files are released and 
subsequent dayfile messages issued. The beginning and EOI 
sectors for each file are validated to see if the user's files 
all there. The status at the time the user was recovery 



a re 



processed is returned in VFST+4. 
returned as 0003. 



The contents of VROT+4 is 



The SALVARE file is always at FNT ordinal 1. If 1TA finds the 
file active or destroyed (unrecognizable at recovery time) it 
hangs with the MXFN monitor function. The format for the file is 
as f o I lows . 
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59 


53 


47 






35 


29 


23 


17 


fo 


eq 




ft 




hrs 


mm 


sec 




ia 


reserved for CDC 




f o 

eq 

ft 

hrs 

i a 

to 



rm n . s ec 



Family equipment ordinal 

EST ordinal of rollout file 

First track of rollout file 

Last entry time in compressed format 

Installation reserved area 

Terminal table ordinal 
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TRANSACTION FACILITY (TAF) 



16 



TAF OVERVIEW 

The transaction subsystem allows the high speed handling of 
repetitive executions of a relatively small number of jobs 
called tasks. That is, the same set of tasks run many times by 
different people to perform the same function. The advantages 
of using a transaction system instead of the time-sharing 
executive functions are as follows. 

• More important tasks may be given higher scheduling 
priority. 

• Tasks may be kept CM resident within the executive to 
eliminate loading time and overhead. 

• I/O requests may be managed by the executive to provide 
orderly data base access where many users are updating 
the same data base. I/O requests are overlapped. 

• Data flow may be optimized by allowing only 
pre-specif ied file structures known to the executive; 
therefore, user jobs need not be concerned with complex 
file structures. 



TAF may communicate to terminals through the time-sharing 

cutive or through Network Access Methods (NAM). NAM uses 



exe 



the 



2550 Host Communications Processor. NAM 
advantages to the transaction product. 



provides the following 



• A Network Definition Language (NDL) . 

• Buffering and queuing of data for regulation of data 
f low . 

• Support of a wide variety of terminals through 
normalization of data formats (code conversion), as well 
as ability to handle transparent data. Synchronous and 
asynchronous terminals may use NAM. 

• Dynamic establishment, maintenance, and termination of 
data paths between terminals and TAF. 

The transaction application user is assumed to be familiar with 
COMPASS, the TAF reference manuals and the TAF Data Manager 
reference manuals. For information related to the ... 
implementation of a transaction application, refer to the list 
of manuals in the preface. 
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The transaction executive is composed of two major functional 
pieces. One is directed to task execution management, the other 
to data base management. Three data managers are available for 
use with the subsystem, the TAF data manager, the TOTAL data 
manager, and the TAF CYBER Record Manager (CRM) data manager. 

A transaction application is implemented by creating a data base, 
defining a terminal network and by writing tasks to perform the 
transaction process. Some of the characteristics of tasks are 
as follows. 

• They must be (00) level overlays placed on a transaction 
task library by LIBTASK. 

• The only RA + 1 requests they may make are those processed 
by the transactions executive. 

• They are loaded and executed at subcontrol points within 
the tranasction subsystem field length. 

These tasks read and update information on the user's data base 
and generate output to the transaction terminals. 

The subcontrol point feature allows the transaction executive to 
maintain complete control over each task. Some of the advantages 
associated with subcontrol points are: 

• Isolation of one subcontrol point from other subcontrol 
points and the transaction executive, guaranteeing 
system security. 

• Blocking of RA+1 direct requests. No PP requests or I/O 
actions are allowed directly from a subcontrol point. 
Any such requests are intercepted by the system monitor 
which returns control to the transaction executive. The 
transaction executive manages resources and provides 
synchronization. 

• Freedom to move, load, and overlay areas within the 
subsystem field length. Since each subcontrol point has 
a relative origin of zero, absolute overlays all 
originating at a given address (for example, 111B) can 
be loaded in any order and at any place within the 
subsystem field length. 

An installation parameter sets the number of subcontrol points 
that the transaction executive initializes. When the transaction 
executive is loaded, the operator may select a number of 
subcontrol points other than this default value. The number of 
subcontrol points must not be less than two or greater than 31. 
Once the transaction executive in initialized, no change in the 
number of subcontrol points is allowed. 
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Each subcontroL point requires eight words of table space within 
the transaction executive. No space, other than a table entry, 
is allocated for a subcontol point unless it is active. The 
optimum number of subcontrol points is selected by the site. 

A data manager controls the structure of user data. In order to 
control this data, the data manager must be supplied information 
about a user, his application area, and installation. This 
information is provided by the user at data base definition time. 

A data base can be defined as this control information together 
with transaction data supplied by the user. 

The transaction data base consists of related data files. Data 
files have specific names that provide a common point of 
reference between user programs and the data manager. Data files 
are structured into groups of i reformation ' cat led records. All 
records in a file must have the same . structure- Records may be 
subdivided into elements. One or more elements may serve as a 
key or identifier for a record. 

At data base definition time, the user supplies a desription of 
all data elements and data files to be contained in the data 
base. 

The information provided to the data manager consists of 
parameters that describe the physical allocation of the data, 
parameters that describe the element characteristics and 
security, and parameters that describe the file organization. 



TAF INITIALIZATION 

TAF uses a procedure file for initialization. For TAF using NAM 
for terminal communications the file is TAFNAM. For TAF using 
multiplexers for terminal communications the file is TAFTS. Both 
indirect access files are under the system's user index, 
applications analyst may modify these files for special 
transaction subsystem initialization or termination. The 
general format of these files is as follows. 



The 



TAFNAM 
CALL, SETUP. 

RFL, 70000. 
1,TAFNAM1 . 
TAFNAM2. 
EXIT. 



TAFTS 
CALL, SETUP. 

RFL, 60000. 
1,TAFTS1 . 
TAFTS2. 
EXIT. 



Purpos e 

Optional. Installation may use 
procedures to set up transaction 
env i ronment . 

Requi red. 

Required for initialization. 

Required for termination. 

Requi red. 
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TAFNAM 

DMD. 

DMD, 0,37777. 

TAFNAM2. 



TAFTS 

DMD . 

DMD, 0,377777. 

TAFTS2. 



Purpose 

Optional. May be used to get dum 
to investigate problems. 

Required for termination. 



IFCSW4)G0T0,1 . IF(SW4)G0T0,1 . . . 

IF(SW5)GQT0,2. I F ( SW5 ) GOTO, 2 . Optional. Dump is printed if 

RETURN, OUTPUT. RETURN , OUTPUT . sense switch 5 is set. 

2, EXIT. 2, EXIT. 



CALL, CLE AN UP. CALL, CLEANUP. 



Optional. Installation may use 
special procedures for cleanup. 



The routine 1SI calls the proper file depending on the DSD 
command used to initiate the transaction subsystem, TAFNAM or 
TAFTS. 

The transaction subsystem is initiated via a DSD console entry 
and is scheduled by the operating system to run until operator 
termination, at control point 2. To use TAF using terminal 
communication via the time-sharing executive type the DSD 
command TAFTS. To use NAM for terminal communication under TAF 
type in the DSD command TAFNAM. 

Initialization consists of attaching files required for 
operation and dynamically establishing internal tables and 
management areas as a result of installation parameters and 
operator K display commands. Parameters dynamically set include 
the number of subcontrol points, number of communication blocks, 
maximum CM and ECS field length, and the number of data manager 
I/O buffers. Files attached include the task libraries and data 
bases . 

Table 16-1 lists the table and buffer pointers used by the 
transaction executive. 
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TABLE 16-1. TABLE AND BUFFER POINTERS 



Word 



Name 



Meani ng 



10 
11 
12 
13 
14 
15 
16 
17 

20 



VNSCP 

VNCMB 

VTST 

VNTST 

VMDM 

VLSP 

VATL 

VFSCP 

VCBRT 



21 


VCBSA 


22 


VTLD 


23 


VEDT 


24 


VPOTT 


25 


VMFL 


26-31 


I VSDB 


32 


| VTFL 


33 


I VREC 


34 


I VCRAT 



Number of subcontrol points 

Number of communication blocks 

Start of terminal status table 

Number of terminals 

Multiple for data manager buffers 

Address of last subcontrol point 

Address of ATL 

Start of subcontrol point allocatable 
storage 

Start of communication block storage 
allocation bit maps 

Start of communication blocks 

Start of task library directory 

Base address of element descriptor tables 

Start of data manager buffer area 

Maximum field length for transaction 
subsystem 

Specified data base(s) 

Task library file name (must follow VSDB) 

Recovery flag 

Start of copied record address table 
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TABLE 16-1. TABLE AND BUFFER POINTERS (CONTINUED) 



Name I Meaning 



VECS 

VECSC 

VCRS 

VROLT 

VRLAT 

VCPA 

VTOT 

VDBA 

VAAM 

VAAQ 



VAMB 


VINT 


VNACP 


VOEP 


VOREL 


VDBA A 


VSTAT1 


VRTLW 


VBSTR 


VNCT 


VNON 


VSND 



ECS field lengt h 

Current next available ECS address 

CRAS terminal name 

Rollout control table 

Rollout file allocation map 

Address of first subcontrol point table 

Total data manager initialization flag 

Transaction subsystem data manager 
i ni t i a I i zat ion flag 

TAF CRM data manager initialization flag 
and FWA of routine to process CRM requests 

FWA of FETs for TAF CRM input and output 
queues 

FWA of AAM record buffer 

Initialization complete flag 

Address of pointer to free subcontrol 
po i nt 

Overlay entry point name list 

Overlay relocation list 

Transaction subsystem data manager status 
wo rd 

Statistics area 

Requested task list 

Transaction subsystem data manager BST 
reservation map 

NAM communication table 

NETON status (zero if NAM is running) 

Application block number for NAM 
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The flowchart in figure 16-1 outlines the routine INIT which 
performs the initialization for the executive and for the data 
manager. The flowchart shows an overview of the transaction 
executive initialization process. The tables and buffers are 
up in subroutine SETL. Following the flowchart, table 16-2 
provides an overview of transaction subsystem memory, showing 
the order of the tables and buffers established during 
initialization. 



set 
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XXP 



a b o r t 



set up system 
d^ta base pro- 
cedure call 



request FL 

for K- 
disolav 



SPF 




set default 
initialization 
pa rame ter s 



SETK 



opera tor 
changes 
pa rame ter s 




read old 

K-di splay 

values 




set up data 
base procedure 
ca 1 1 s 





<D 



execute 

procedure 

call s 



endrun 



Figure 1 6-1 . 



INIT - Initialize 
Transaction Executive 
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SYSTEM 

call 1TD to 
set running, 
FL 



load TAF 
data manager 
if required 



load NAM appli- 
cation inter- 
face program 
if required 



load TOTAL 
data manager 
if required 



load TAF 

GRM data 

manager if 

required 



SETL 



' alloca te 
^variable tables// 
buffers 



flush 

recovery 

file 



pass 
recovery 
flag to 
executive 



OVERLAY 



load 
transaction 
executive 




Figure 16-1. 



INIT - Initialize 

Transaction Executive (Continued) 
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TABLE 16-2. BUFFERS AND TABLES 



Address 
LAST 



Cont ent s 



Notes 



Transaction 
execut ive 



Data manage r 



LASTN+1 



Subcont ro I po i nt 
tab Le 



Number defined in VNSCP 



VCBRT 



B i t map s for 
c ommun i c at i on 
blocks (CB) 



Number defined in VNCMB 



VC3SA 



Communication 
blocks 



Number defined in VNCMB 



VATL 



Active t rans 
action list 



One word per CB; each entry points 
to a CB 



TST 



Terminal status 
t ab le 



Built from NETWORK file or SIMFILE 
Entries sorted on MUX channel, 
equi p, port key. 



VNCT 



Network Commun i - 
cation table 



Three words per connection. The 
first word points to the TST, the 
second contains the supervisory 
message, the third contains the 
application block header. 



VEDT 



EDT 



Contains FETs for journal files, 

etc. 



VCRAT 



CRAT 



Records from XX data base ERPF 
error recovery pool file 



Bu f f e rs for 
journal files 



Pointed to by FETs in EDT above. 
2002B words for MT, 402B words for 
disk. 



VTLD 



Task library 
di rectories 



VPOTT 



Data manager 
buffers 



Space allocated by transaction 
subsystem initialization but no FET 
poi ne rs set. 



VFSCP 



Sub cont ro I 
points 



RA+FL 
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SUBCONTROL POINT TABLE 

The structure of the subcontrol point table as established by 
SETL is as follows. 



LASTN + 1 

CPAL-10B 

CPAL =10B 

CPAL-10B 



VLSP 
VC8RT 



FL=0 RA1 



Fl=0 RA2 



FL=0 RA3 



FL = Q RAn 



+J 
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The format of the subcontrol point table entry is as follows 



word 1 



59 53 47 




tdc 



fc 



nc 



35 



17 




fl 



entry point 
address of task 



ra 



cc 



ns 



cba 



s 
P 

f c 
f I 
ra 



d 
c 
r 
a 
nc 

c c 



Do not storage move this subcontrol point (bit 59) 

Can release this subcontrol point if core is 

needed (bit 58) 

Available free core after subcontrol point 

Subcontrol point FL 

Subcontrol point RA 

If set, task is a system task and gets entire 

communication block (bit 59) 

If set, task code is reusable (bit 58) 

If set, task is CM resident (bit 57) 

Recall status bit (bit 56) 

If set, task is to be aborted (bits 55 through 54) 

Number of communication blocks at subcontrol 

poi nt 

Address of status word for communication block 

now i n execut i on 



nm Task directory index 
Is Last subcontrol point 
ns Next subcontrol point 

x Communication stack is present at subcontrol 

point (bit 59) 
i Initial communication block load 
cba Communication block FWA address 
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The Length of the subcont roL point entry is 108' words. Thus, 
there are five words of type N. The length Af an entry is 
defined by CPAL and must be a mu Lt i pie „ ; of 1 0B . ; 



COMMUNICATION BLOCKS 

The communication block is used to pass input received by the 
transaction executive from a : . t e rm.i na I to a t a sk; It may also be 
used by tasks to pass along information, to another task. It is 
sometimes used by the t ransact i on executi ve to pass system 
information to a transactipn system task. 

Each new transaction message received by the transact i on 
executive is sent, in a communication bloc,k y .to 1TASK. ITASK 
then selects the appropriate t ask ( s), ; to call to process the 
■input.' .,-.;. ■*■■:■■■:■.. 

Communication blocks are set up by SETL by reserving CMBL. times 
NCMB words. CMBL is the length of one entry and is equal to O 
words (a 6-word system header and 69 wo rds of da t a ) . NCMB is 
the number of communication b locks (1,0. by. def.au It ). A It hough not 
written duri ng i ni t i a li za t i on, the format of the 6-word system 
header is formatted as follows (not accessible to nonsystem 
task). 



word 1 



CBCR 




cp 
r 

m 

ca 
t 

seq 
d re 



CPU priority 

Recall on all outstanding data manager requests 

46) 

At least one message was sent to terminal (bit 45) 

Transaction chain has aborted (bit 44) 

Task initiated by a CALLRIN (bit 43) 

Primary sequence communication block address 

Data manager requests currently outstanding 



(bit 
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t so 
rs 

ws 

t St 

cba 



Termi rial ordi na I 

Terminal data base read security level (bits 41 
through 39) t , 

Terminal data base write security level (bits 38 

through 36) 

Address in TST for terminal 

Communication block address 



1 t 
2t 
3t 
4t 
5t 

a 

b 
c 
mc 

I wa 
f wa 

qd 
ot 

qi 

nl 

cp 

ta 

rf 

res 

d 



Next task schedule 

2nd task in chain to schedule 

3rd task in chain to schedule 

4th task in chain to schedule 

5th task in chain to schedule 

Valid DSDUMP request (a=1) (bit 59) 

Dump exchange package (b = 1) (bit 58) 

Dump data base buffers (c = 1) (bit 57) 

Count of multiple communication blocks used for input 

(bits 56 through 48) 

First word address of task dump 

First word address of task dump 

Queue designator (see K. DSDUMP) 

Origin type value of queue destination (bits 14 

t hrough 1 2) 

Queue destination indicator 

Next level of current task if called by CALLRTN 
Subcontrol point number last CALLRTN task 



Called with return task 
Called with return flag 
Rese rved 
Data manager flag (bits 



has aborted (bit 47) 
(bit 46) 



21 through 18): 

1 Transaction subsystem data manager 
requests allowed. 

2 Total data manager requests allowed. 

4 TAF CRM data manager requests allowed, 
rta Rollout table entry address 



60454300 B 



16-14 



The communication block user header is formatted as follows 
(accessible to all user tasks). 



59 



word 1 



47 



db 



UQ 



tn 



23 17 11 



seq 



flags 



wc 



db 
ua 
seq 

tn 

f lags 



w c 



Data base that the terminal is validated to use 

User area 

Transaction sequence number 

Te rmi na I name 

Each bit defined as follows: 



Bi t 
17 
16 



15 

14-13 
12 



Desc ri pt i on 
System origin transaction if set 
Parity error occurred on terminal 
i nput i f set 

Transaction input came from batch 
rather than terminal if set 
Unused 
Multiple communication block if set 



Word- count of terminal input data for this 
communication block 
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ACTIVE TRANSACTION LIST 

The active transaction list (ATL) as established by SETL 
contains a one-word entry for each communication block. Each 
ATL entry contains a pointer to a communication block. The 
format of the ATL entry is as follows. 



59 



nt 



47 



pt 




cba 







nt 
pt 
cba 



Next task in queue chain (biased by +1) 
Previous task in queue chain (biased by +1 ) 
Address of communication block 



TERMINAL STATUS TABLE 

The terminal status table (TST) contains a two-word entry for 
each terminal described in the network file or simfile 
stimulation. The list of entries is sorted according to 
multiplexor channel, equipment, and port key. For a description 
of the network file, refer to part IV, section 3 of the NOS 
Installation Handbook. The format of the TST entry is as 
f o I lows . 



word 1 



59 55 50 47 41 38 35 



23 17 11 



do 



ch 



u w 



w 

I 

d 

o 

ch 

eq 

Pt 

r s 

us 

db 

ua 

tn 

m 

ct 



eq 



pt 



rs 



us 



db 



ua 



tn 



m 



ct 



nt 



Interactive task waiting for input 

Terminal user active 

Te rmi na I down 

Te rmi na I on/off 

Multiplexor channel * 

Multiplexor equipment * 

Mu It iplexor port * 

Data base read security level 

Data base update security level 

Data bsse terminal is validated to use 

Use r area 

Te rmi na I name 

Multiple block input being sent 

Character type for terminal 



nt Number of transactions received from terminal 



* For TAFNAM this area is used as 
communication table (NCT). 



an ordinal into the network 
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After SETL completes the initialization of the tables mentioned 
previously, routine IDM initializes the transaction subsystem 
data manager using the remaining field length. IDM attaches the 
data base identification f i le (DBI D) . The contents of the file 
are read into memory (error if not enough room) and written to 
the recovery file. The entries in the file contain data base 
names for the element descriptor table (EDT) files which must be 
attached. However, before proceeding, subroutine SDT is executed 
to allow the operator (via the K display) to specify up to three 
data base names. The procedure is outlined in the following 
steps for data base i ni t i a I i zat i on : 



1 



2. 



Attach xxJ file for this data base (xx is the data base 
name specified in the DBID file). This file provides the 
user number and password which are stored in the EDT 
header. 

Call subroutine INT in common deck COMBINT. This 
routine attaches the journal files described in the xxJ 
file attached in step 1. Trace and pool files (xxTFIL 
and xxERPF) are assigned FETs. The EDT header is 
initialized followed by the EDT entries for this data 
base as specified in file xx ( xx = two-charact er data base 
name). The EDT header is described later. 



4. 



A call to subroutine ATT attaches the pool and trace 
files (xxERPF and xxTFIL). 

Gall xxJ again. xxJ establishes FETs for the journal 
files (maximum of 3), and calls ATT to attach them. 



The preceding process continues for all known data bases. Next, 
the copied record address table (CRAT) is initialized by 
subroutine ICRT. The subroutine reads the error recovery pool 
files (xxERPF) for the various data bases. Any records found in 
these files are placed into the CRAT. The CRAT is defined to be 
CRATL words long (currently CRATL equals 100B). If more records 
exist than will fit into the 100B word table, transaction 
initialization aborts. 

After initializing the CRAT, IDM calls subroutine ABJ to 
allocate circular buffers for journal files. Tape and disk 
buffer sizes are defined by symbols TAPL and DSKL, respectively. 

Currently, TAPL equals 2002B, and DSKL equals 402B. 

Next, the last subroutine, LTL, is called. This subroutine 
loads the system task library di rectory , TASKLIB, and xxTASKL 
(xx is data base name), the directory for each data base. These 
directories have been created by subsystem utility, LIBTASK, and 
occupy the last file of the task library. 
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of the transaction executive and begins execution at the preset 
rout i ne PRE . 



TOTAL DATA MANAGER INITIALIZATION 

The steps for TOTAL initialization are as follows:. 



Attach TOTAL binaries 

Get data bases from TDBID file 

Attach TOTAL data base files 

Pass names of TOTAL data base files to TOTAL via loader 

request . 

Use CYBER Loader to load TOTAL 

Call INTOT. to initialize TOTAL. INTOT. is a TOTAL 

rout i ne . . 

Save entry points of TOTAL in VTOT. Routine PRESET will 

set up calls to TOTAL . 

Process xxJ files for TOTAL. The xxJ files give the name 

and residency of TOTAL data base files. 



TAF CRM DATA MAN AGER . IN IT I AL IZAT ION 

The steps for initializing the TAF CRM data manager are as 
f o I lows : 



1 . 

2. 
3. 



4. 



Use CYBER Loader to load CRM and Common Memory Manager 

(CMM). 

Get data bases from CDBID file. 

Process xxJ Cxx equals data base) to attach CRM files 

and allocate space for CRM file environment tables 

(FETs/FITs) and record lock tables. A buffer is also 

allocated for the largest record. 

Link calls in TAF executive to entry points in TAF CRM 



TASK LIBRARY DIRECTORY 

The task library directory header is formatted as follows. 



word 1 



59 


53 




35 


29 


17 




11 


5 


task name 


entry point 


disk address 


field length 


bp 


mp 


flags 


tl 


tc 


ql 
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bp Base priority 

mp Maximum priority (future use) 

flags 



Bi t 



Description 



59 System task 

58 Nondestructive code 

5 7 CM resident 

56 Library copy in ECS 

55 Task turned off by operator 

54 Task deleted 

53 Solicit input 



tl Number of times task was Loaded 
tc Number of times task was called 
ql Queue length limit 



FILES USED BY THE TRANSACTION SUBSYSTEM 

When the transaction subsystem is initialized, the following 
files must have been set up. 

NETWORK File 

This file contains the description of each terminal Cthat is, 
the data base it has access to) which may communicate with the 
transaction subsystem (refer to the NOS Installation Handbook).* 
This file is used to build the terminal table which may be 
displayed with the 0,TR display. 

DBID/TDBID/CDBID Files 

The files that tell which data managers and data bases to 
initialized.* 

Procedure Files SYPR, xxPR 

Initialization procedure files, where xx is the data base name of 
a data manager data base.* 

x x J File 

The file which identifies the xx data base user number and index, 
the journal files, the residency of data base files, and the data 

base task library. 



•Refer to the TAF reference manuals or the TOTAL Reference 
Manua I 
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EDT/DPMOD Files 

The data manager data base descriptor files; EDT is for the Data 
Manager data base and DBMOD is for Total data base.* 

TASKLIB/xxTASKL Libraries 

The transaction subsystem system task library, TASKLIB, and the 
data base task libraries, xxTASKL.* 

J ournal Files 

JOURO is the transaction subsystem journal file. Each data base 
may have up to three additional data base journal files xxJORl, 
xxJ0R2 and xxJ0R3.* 

ERPF File 

The error pool file used by the TAF Data Manager to record file 
error recovery data.* 

Trace Fi les 

The Data Manager data base, xxTFIL, journal, log or trace of 
activity.* 

xxTLOG File 

The Total data manager data base journal, log, or trace of 
activity.* 

SPECIAL RESERVED FILES 

The following files are reserved by TAF while executing: 



File Name 
KTSROLL 

OUTPUT 
RECOVR 

SCRA, SCR4 

SCR5 

TROB 



Description 

Task rollout file used to roll out tasks 
a s needed . 

Output file. 

Contains a copy of the low core pointers 
of TAF. 

Used by TAF for tape journal files. 
Sc ra tch file. 

Used by TAF to roll out part of its own 
field length . 



•Refer to the TAF reference manuals or the TOTAL Reference 
Manua I . 
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The use of these file names by an application at the TAF control 
point or attached in a procedure file called by TAF may result 
in an error . 



TRANSACTION EXECUTIVE 



the Loader and 



The transaction executive is Loaded at TFWA by 

begins execution at the preset routine, PRE. In. general, PRE 

completes the i.ni.t i aU zat ion ' started by transaction 

initialization. The preset routine performs the followin 



1 . 



2. 



5 . 



6. 



7. 



g steps 



Call subroutine SETA to modify the 30-bit increment ^ 
instructions to eliminate the need for reading up pointer 
words (V-words) when referencing tables. 

Call PVV to set variable values, such as maximum field 
length (MFL)/ current field length (CURFL), and available 
central memory CAVA I LCM) . 

Call LIT to load the initial task from system task library 
to. subcontrol point one. Initial task remains at 
subcontrol point one. 

Call LCT to read task library directories and Load CM- 
resident tasks at subcontrol points. If more tasks than 
subcontrol points available, abort. 

Call IJF to position each j ourna I f i le to EOI and write a 
label containing the current date. 

Call SIC to initialize intercontrol point transfers. 
Terminal input, batch input, and LIBTASK status messages 
are done via intercontrol point transfers. 

If NAM is to be used for terminal communications do a 
NETON. 



8. Jump to TMDC to begin main processing 



shown in figure 



A memory map of the transaction subsystem is 
16-2 for TAFTS and figure 16-3 for TAFNAM. The purpose of the 
three SEG instructions is to allow COMPASS to ;write.partial 
binaries during assembly. Thus, less memory is required to 

perform the assembly. 
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RA 


buffers and pointers 


1 




TMDC 


time dependent routine control 






PRIN 
TRO 

TRI 

TRFL, 
TSSC, 
TRFL 
SCHD 

SCT 

CIC 
RMEM 

JRNL 
KDIS 

ENDT 
LASTF 

LASTN 


process transaction input 






rollout routine (TRO) 






rollin routine (TRI) 


• Block 1st 


' 


routine to check and activate 
sub-control points for time slice 






task scheduler 






RA + 1 request processors 


*SEG 




miscellaneous subroutines 


\ 




CM request processors 






journal file processing 






error processing 




rollout file 
when 


update K display (if FL dumped, 
this is destroyed by DMP) 


• Block 2nd 


transaction 
subsystem 
is inactive 


tables RTL and CCC 




common decks (COMCxxx) 






fixed length buffers 






overlays 


SEG 




C0M8DBM transaction subsystem 
data manager 


| Block 3rd 
) SEG 




COMBELP, COMBACT, COMBSCT, COMBACM 


Block 4th 




TOTAL data manager 






TAF CRM data manager 




start of tables 



Figure 16-2. Transaction Subsystem Memory Map - TAFTS 
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written to 
rollout file 

when 
transaction 
subsystem 
is inactive 



RA 

TMDC 

PRIN 

TRO 

TRI 

COMKNWC 

TRFL, 
TSSC, 
TRFL 
SCHD 

SCT 

CIC 
RMEM 

JRNL 

KDIS 



ENDT 
LASTF 



LASTN 



network application interface program 



time dependent routine control 



process transaction input 



rollout routine (TRO) 



rollin routine (TRI) 



process network communications 



routine to check and activate 
sub-control points for time slice 



task scheduler 



RA+1 request processors 



miscellaneous subroutines 



CM request processors 



journal file processing 



error processing 



update K display (if FL dumped, 
this is destroyed by DMP) 



tables RTL and CCC 



common decks (COMCxxx) 



fixed length buffers 



overlays 



COMBDBM transaction subsystem 
data manager 



'Block 1st 



SEG 



► Block 2nd 



COM8ELP, COMBACT, COMBSCT, COMBACM 



TOTAL data manager 



TAF CRM data manager 



start of tables 



SEG 

Block 3rd 
SEG 

Block 4th 



Figure 16-3. Transaction Subsystem Memory Map - TAFNAM 
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The symbol TRFL is defined at the end of subroutine TRI and is 
rounded up to the nearest 100B. The field length from this point 
to the end is written to a rollout file by subroutine TRO when 
no transaction activity is occurring. 

Subroutine TRI will read the file, thus rolling the field length 
back into the control point. This occurs when transaction input 
is received by subroutine PRIN or when the rollout time slice 
(TROTL) has elapsed (to ensure time-originated tasks are 
act i vated) . 

Location ENDT marks the end of the run time code and the 
beginning of the fixed length buffers. Location LASTN marks the 
end of the buffers and the beginning of the tables and buffers 
set up by initialization. The fixed length buffers and their 
sizes are listed in table 16-3. 



TABLE 16-3. BUFFERS AND LENGTH 
Buffer 



Length I 


1201B I 


20B I 


30B I 


12B I 


30B I 


401B I 


100B I 


170B I 



JBUFO 

DIBF 

DOBF 

TDIBFL 

TDOBFL 

OBUF 

SBUF 

PBUF 



J ournal File 

Data Manager Input 

Data Manager Output 

TOTAL Data Manager Input 

TOTAL Data Manager Output 

Output Buffer 

Scratch Buffer 

Internal Trace Buffer 



Time dependent routine control consists of one routine named 

TMDC. TMDC calculates elapsed time for various subroutine calls 

If the time limit for a particular routine has been exceeded, 
that routine is called. Subroutines called by TMDC include: 

NGL Get terminal input from NAM 

PRIN Process transaction input 

SCHD Schedule tasks 

DCPT Drop CPU for a task 

KDIS Update K display 

CORU Check core usage 

TRN Check transaction activity 

JSTS Write statistics to journal file 

TSSC Activate subcontrol points 



60454300 B 



16-24 



The data manager (DM) is called by subroutine TSSC only. The 
data manager returns control to TSSC at a location defined by 
symbol TSSCQ. The batch TAF data manager interface routine, 
BDMI, also adheres to this convention. 

DM requests are queued and several issued at one time. 

Figure 16-4 illustrates the flowchart for the transaction 
subsystem main loop. The TSSC routine is flowcharted in figure 
16-5, 
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(TMDCJ 



get 
current 
time 



check for 
terminal 
input 



everv 20 MS 




DCPT 



prepare to 

activate 

task 



Figure 16-4. Transaction Main Loop 
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KDIS 



up da te 
K-display 



SRL 



check for 

task time 

outs 



AIQ 



increment input 
queue 
priorities 



PBT 



prepare batch 

submitted 
transactions 



CORU 



check core 
usage 





JSTS 



write statis- 
tics to journal/ 
file 



CRF 



set up FET 
for rollout 
file 



recall 



time slice 
subcontrol 
points 



TSSC 



•1 Time to start tasks which have been rolled out for n seconds 

*2 Ensures new tasks are not started before starting a waiting 

t ask . 

•3 Check for memory increase or decrease. 



Figure 16-4» Transaction Main Loop (Continued) 
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TSSC 




run data 
manager 



process 

data 
manager 
replies 



run total 

data 

manager 



process 
total data 
manager 
replies 



schedule 
task 



retry SIC 




no 




no 



Figure 16-5. TSSC Loop - Task Slicing 
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( REC^ 




Figure 16-5. TSSC Loop - Task Slicing (Continued) 
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move 
:ommunicatian 
block to 
task 




no 



set up 
RA,FL,P 



a c t i va t e 

subcontrol 

point 





Figure 16-5. TSSC Loop - Task Slicing (Continued) 
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SUBCONTROL POINT PROGRAM REQUESTS 

Subcontrot point reuests are passed to the transaction 
subsystem through RA+1. The format is as follows. 



59 



RA + 1 



name 



41 



35 



arg 



name Request name 

r 20B if auto recall desired 

arg Arguments 

The recall parameter is of use only on data manager requests, as 
all other requests are answered immediately by the transaction 
executive. 

If the request is not of the above format, the task is aborted. 

The following paragraphs illustrate the individual request 
formats. 



SCT - SCHEDULE TASK 
59 



35 



17 



SCT 



fnc 



addr 



fnc 



Schedule function code: 



Task cease - end current task 

1 NEWTRAN - start a new transaction 

2 Call task with cease 

3 Call task without cease - start an asynchronous 
task chain 

4 Call task with return 

5 Wait for terminal input 

6 Ti med rol lout 

7 CHKON - set Total interlock flag 

8 CHKOFF - clear Total interlock flag 

9 BWAITINP - return terminal input to a 
specified buffer, not restricted to the 
traditional communication block location (FWA 
of load) 

addr Parameter address 
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DBA-DATA BASE ACCESS 
59 



35 



17 



DBA 



fnc 



addr 



fnc Data manager function code CO through 177 is 
handled by the data manager with no special 
processing in TAF; 200 indicates recall on all 
outstanding data manager requests): 



Code Name 



1 
2 
3 

4 

5 

6 

7 

8 

9 
10 
1 1 

12 

13 
14 
15 
16 

17 
18 
19 

20 

21 
22 
23 
24 
25 
26 
27 
28 

29 

30 
31 
32 
33 
34 
35 



GETT 
GETL 
GETN 

GETNL 

GETB 

GETBL 

GETR 

GETRL 

GETNR 

GETNRL 

GETRB 

GETRBL 

PUT 
PUTF 
PUTI 
PUTIF 

PUTR 

PUTRF 

PUTRI 

PUTRIF 

ADDR 

UNLOK 

UNLOKAL 

REPOS 

PURGER 

RECHAIN 

RELES 

RELESAL 

Cease 

BLKGET 

BLKPUT 

LOCKF 

UNLOCKF 

OFFTRCE 

ONTRCE 



Description 
Get elements 
Get elements and lock 
Get next record's elements 
( f o rwa rd) 

Get next record's elements 
and lock (forward) 
Get elements from record 
before this one (backward) 
Get elements from record before 
this one and lock (backward) 
Get record 

record and lock 

next record 

next record and lock 

record before this one 
(backward) 

Get record before this one and 
lock (backward) 
Put elements 

elements and force write 

elements in current record 

elements in current record 

force write 

record 

and force write 

in buffer replacing 



Get 
Get 
Get 
Get 



Put 
Put 
Put 
and 
Put 
Put 
Put 



in buffer replacing 
force write 



record 

record 
cur rent 
Put record 
current and 
Add record 
Un lock record 
Un lock all records 
Repos i t i on 
Purge a record 
Rechain record 
Replace buffer space 
Replace all buffers held by this 
user 

TAF issues this request to the data 
manage r 

Block get of records 
Block put of records 
Lock f i le 
Unlock f i le 
Turn off trace 
Turn on trace 
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Code Name Description 

36 DMSTAT Return data manager buffer status 

37 CLEAR Clear 

38 READEDT Read element descriptors from the 

EDT 

NOTE 

The READEDT function is 
not assembled into the 
data manager by default. 
It is assembled when the 
COMBDBM symbol CREDT is 
equated to a nonzero value. 

addr Start of data manager parameter area 

A more detailed description of the data manager commands can be 
found in the TAF Data Manager reference manuals (refer to 
preface) . 



TOT - ENTER REQUEST INTO TOTAL DATA MANAGER QUEUE 

35 1Z 



59 



TOT 



fnc 



addr 



fnc Total data manager function code 
addr Parameter list address 

AAM - ENTER REQUEST INTO TAF CRM AAM QUEUE 



59 



35 



17 



AAM 



fnc 



addr 



fnc Advanced Access Methods (AAM) function code 
addr Parameter list address 
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CTI 



- CALL. TRANSACTION SUBSYSTEM INTERFACE 




f nc 



Request code: 




1 
2 

3 

4 

5 

6 

7 

8 

9 
10 
11 
12 
13 
14 
15 

16 
17 
18 
19 
20 
21 



message to a 



transaction terminal 



Send a 

Make a journal file entry 

Check for a specific transaction still 

Process terminal argument operation 

CMDUMP request 

DSDUMP request 

Return terminal status 

K-di sp lay command 

Use task data field for K display 

Reserved 

Submit batch job 

Increase time limit 

Increase I/O Limit t 

Log out dial-in transaction terminal 

Read multiple communication block in P^ 

Release extra multiple input communication 

b locks 

Set terminal character type 

Define terminal type 

Get terminal application block header 

Abort task; task request argument error 

Return active teleprocessor 

Return communication block 

location in the task's memory 



code 
to specified 



addr Address of parameter list 
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SEND TERMINAL OUTPUT 



addr + O 



+ 1 



+ 2 



+3 



59 


53 


47 


29 


17 


flags 





fwa of message 





number of words 
in message 


terminal name 


block number 


application block header 


status 



flags Each bit is defined as follows: 
Bi t Desc ri pt i on 

59 Send to terminal specified in addr+1 if 

bit set; otherwise, send to originating 

t e rmi na I 
58 Task cease request if set 
57 Output flag; if set, more sends are to 

f o I low 
56 Return application block number if set; 

applies to TAF using NAM 

55 If set, task must wait for block to be 

delivered to terminal 
54 If set, user supplied application block 

header at addr+2 

status NAM supervisory message returned if task send 
waited for block to be delivered to terminal 



TASK JOURNAL REQUEST 



addr 



59 


53 




35 




17 










in 


num 


msg 



msg FWA of block to be journalized 

num Number of words to write to journal file 

jn Journal file number 
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CHECK FOR TASK CHAIN IN SYSTEM 

59 41 

addr . seq 



17 







stat 



seq Sequence number of transaction 

stat Set stat to zero if transaction not in system 



59 




29 


17 





terminal name 


return address 


value 


mask 



REQUEST CODE 3 - TERMINAL ARGUMENT OPERATION 

addr + O 
+ 1 



Terminal name identifies terminal to be operated upon. If zero, 
originating terminal is assumed. 

Return address is location to place result of operation (in 
addition to terminal table). Zero if no return desired. 

Value is a value to be used to alter terminal arguments, and 
mask is a 24 bit mask. 

The user argument area (24 bits in each terminal table entry) is 
operated upon as follows: 

Return = USER ARG=(USER ARG . AND . MASK) . XOR .VALUE 

Non-system tasks may alter terminal arguments only for those 
terminals that share the originating terminal data base. 

REQUEST CODE 6 - RETURN TERMINAL STATUS 





59 


53 


47 






29 




17 







+ 





code 


list 


leng 


return 


+1 


mask 


+ 2 








crit 
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code 



c ri t 
Leng 
L i st 



mask 
return 



IF data base name field is to be searched 

1 IF user argument field is to be searched 

2 IF communication line field is to be searched 

3 IF terminal name field is to be searched 
Criterion value for search 

Number of words that list can hold 

FWA of list of returned terminal entries; if zero, 

no list 

ent ri es 

A value 

Addres s 

found 



is returned, but the number of found 
will be returned as specified below 
taken as a binary mask 
in which to place the number of entries 



The field specified by code is examined in each terminal table 
entry by taking the logical product of the field and mask and 
then taking the logical difference of this product and grit. If 
this result is zero, the terminal entry is placed into list and 
the number of found entries is incremented. 



CMDUMP 



59 55 



addr+O 



+ 1 



+ 2 



+ 3 



ab 



47 



41 



29 



Iwa 



17 











fwa 



qd 



ad 



fn 



oq 



nf 



e Dump exchange package 

d Dump data manager buffers 

a Use default exchange package parameter 

b Use default data manager parameter 

Iwa Last word address of task to dump 

fwa First word address of task to dump 

oq Output queue 

qd Queue destination 

ad Address user called from 

nf Number of specified files 

f n Speci f ied file name 
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DSDUMP 



59 


55 


47 


Z9 


17 


addr+O ed 


ab 


Iwa 





fwa 


+ 1 


qd 


oq 



e Dump exchange package 

d Dump data manager buffers 

a Use default exchange package parameter 

b Use default data manager parameter 

Iwa Last word address of task to dump 

fwa First word address of task to dump 

oq Output queue 

qd Queue destination 



KPOINT - TERMINAL K-DISPLAY COMMAND 



59 



addr 



start of K- display command 



SET K-DISPLAY TO RUN FROM TASK 



59 



addr 



KCW — K- display control word 



KCW K-display control word 
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SUBMIT JOB TO BATCH 
59 53 
addr 



35 



23 



pru 



byte count 



Contents of addr is the first control word for the output job 
data . 

PRU is number of 60-bit words in each PRU on device. Byte count 
is number of bytes in this PRU. The block of information 
starting at addr is set up in control word format. 



ITL - INCREASE TIME LIMIT 



59 



11 



addr 



tl 



1 1 



New time limit in XJ time units 



Each call to this function decrements the CPU priority of the 
task until zero is reached. Subsequent calls do not affect the 
CPU priority. 



110 - INCREASE I/O LIMIT 



59 



17 



addr 



10 



io New I/O limit in RA + 1 calls 
SEND TERMINAL STATUS FUNCTION TO COMMUNICATION EXECUTIVE 



59 



17 



addr 



terminal name 



code 
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LOADCB - READ MULTIPLE COMMUN IC ATION BLOCK INPUT 



59 



addr 



47 



29 



17 







len 



buf 



r 

ten 

buf 



Release extra communication block(s) after transfer 
Length of buffer in task to receive data 
FWA of buffer in task to receive data 



TIM - REQUEST SYSTEM TIME 



59 



TIM 



41 35 



op 



23 17 







addr 



op Time option 

addr Address for response 

The contents of addr depend on which of the following time 
options is selected. 

• Seconds (op=0) 
59 56 __ — 



11 



addr 



seconds 



millisec. 



Date (op = 1) 



59 



addr 



Ayy/mm/dd. 
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• Clock (op = 2) 



59 



addr 



Ahh.mm.ss. 



• Julian Date (op = 3) 



59 



35 



addr 






Ayyddd 



Rea I Time (op = 5 ) 



addr 



59 


35 


seconds 


milliseconds 



• Packed Date/time (op = 6) 



addr 



59 


35 


29 


23 


7 


11 


5 





y-70 


mm 


dd 


hh 


mm 


ss 
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MSG - PLACE MESSAGE ON LINE ONE 



59 



35 



MSG 



fnc 



23 17 







addr 



fnc Function code 

addr Address of message to be displayed 



RA+1 REQUEST PROCESSING 

Most of the RA+1 request processing routines described 
previously enter the TSSC subroutine upon completion of the 
request. TSSC is the subcontrol point supervisor which activates 
a subcontrol point via the XCHNGE macro. TSSC determines which 
subcontrol points are requesting the CPU and SRTN determines what 
servicing to schedule upon return of the CPU from a task. If 
there are any outstanding data manager requests, TSSC branches to 
the data manager(s) before activating a subcontrol point. 
TSSC also monitors PP completion statuses and reinitiates 
routines when their PP call is complete. For example, TSSC 
restarts task loading after a PP has performed the load, or TSSC 
restarts nonbuffered journal file processing as PP completion is 
sensed. Finally, at absolute time intervals, the system monitor 
drops the CPU from a subcontrol point so that control can be 
returned to the main loop for time-dependent processing. This 
time interval is defined by symbol TSKTL and is currently 120 
milliseconds. Control returns at SRTN which checks error exit 
flags and RA+1 requests from the subcontrol point program. 
Under certain conditions, SRTN calls TXT, the internal task XJP 
trace processing subroutine (for more information concerning the 
trace, refer to Internal Task XJP Trace in this section). If an 
RA+1 request is present, one of the processors described 
previously is executed. 

TASK SCHEDULING 

TMDC calls the task scheduler CSCHD) every SCHTL milliseconds 
(currently SCHTL=6Q) . SCHD searches the requested task list 
(RTL) for the highest priority task, requests enough memory to 
run the task (via subroutine RMEM), and (if memory is 
available) initiates loading of the task. The RTL is one of 
two tables assembled and not set up dynamically by 
initialization. The other table is a task load request stack 
with the name CCC. The RTL consists of two-word entries and is 
currently 120B words long; while CCC consists of three two-word 
entries with a zero-word terminator. The format of these two 
internal tables is as follows. 
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RTL - REQUESTED TASK LIST 



59 



47 41 



name 



fl 



cr 



cr 



29 23 17 



cp 



mp 




5 



sd 



i 



re 



name Task directory index 

fl Field length 

cp Current priority 

mp Maximum priority (future use) 

I Queue length limit 

cr Current ATL entry 

1s First ATL entry 

s System task 

d Non destructive code 

c CM resident 

e ECS resident 

re Rollout table entry address of task to roll in 
(if for a task roll in request) . 



CCC - TASK LOAD REQUEST STACK 



59 


53 


35 


29 


17 


r 


usn 


tfl 


scp 


tin 


rda 



r 

usn 

tfl 

scp 

tin 

rda 



Task rol I in f lag 

Address (-2) of user 

Task field length 

Start of subcontrol point FL 

Address of task library name 

Random disk address of task 



number for task library 
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TRANSACTION EXECUTIVE RECOVERY /TERMINATION 

In general, recovery/ termi nat i on involves the following 
ope rat ions : 

• Flush buffered journal files 

• Flush TOTAL data manager buffers 

• Close CRM files 

• Issue statistics to the dayfile 

• Restart the subsystem 

Figure 16-6 is a flowchart of REC, the main control portion of 
recovery/termination. 
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Figure 16-6. REC - Recovery/Termination 
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TRANSACTION SUBSYSTEM CONTROL POINT 

Figure 16-7 shows the breakdown of the TAFTS control point. 
Figure 16-8 shows the breakdown of the TAFNAM control point. 
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Figure 16-7. TAFTS Control Point 
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Figure 16-8. TAFNAM Control Point 
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TAFTS/TIME-SHARING EXECUTIVE INTERFACE 

The relationship between TAFTS and the multiplexer time-sharing 
executive is shown in figure 16-9. The time-sharing executive 
runs at control point 1, while the transaction executive runs at 
control point 2. This avoids a storage move of the two 
executives which would be necessary if they resided at other 
control points. Transactions are passed between the transaction 
executive and the time-sharing executive via inter-control point 
communication. That is/ the CPUMTR function, SIC, is used to 
transfer data between control points. 
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Figure 16-9. TA FTS/Ti me-Shari ng Executive Relationship 
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TRANSACTION SUBSYSTEM/NAM INTERFACE 

The relationship between TAFNAM (using TAF Network Access 
Method) and NAM is shown in figure 16-10. NAM may run at any 
control point. Routine NGL formats the input from NAM to look 
like time-sharing executive input. Processing of terminal input 
then is done exactly as for the time-sharing executive. 
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TRANSACTION COMMUNICATION FLO W 

The following paragraphs describe the flow of communications for 
terminal login, terminal input, task scheduling, and terminal 
output . 

TERMINAL CONNECTION TO TRANSACTION SUBSYSTEM 

Polled terminals on dedicated lines that are in the network 
file are defined as always connected to the transaction 
subsystem. 

Terminals under the time-sharing executive that are in the 
network file become connected to transaction subsystem by issuing 
the time- sharing command TRAN (refer to the NOS Time-Sharing 
Reference Manua I) . 

ITASK is notified through a special communication block that a 
new terminal has been connected to transaction subsystem (refer 
to the TAF reference manuals). 

When TAF uses NAM for terminal communications, terminal 
connections are controlled according to the NAM network 
configuration file (refer to the Network Definition Language 
Reference Manual). Terminal connection may occur: 

1. By terminal operator typing TAF in response to the 
Network Validation Facility (NVF) application prompt. 

2. By terminal operator doing a login. Upon login, terminal 
is automatically connected according to NAM network file. 

3. By placing terminal in operating condition. Login and 
application connection are done according to NAM network 
file. Terminal may be dedicated or dial-in. 

TIME-SHARING EXECUTIVE TO TAF LOGIN 

The login procedure to the time-sharing executive is as follows: 

1. The time-sharing executive does an intercontrol point 
transfer to the transaction executive with a function 
code of three (packed exponent) in the first word or the 
terminal name in the second word. 



2. 



Either the inner loop, TSSC, or the outer loop, TMDC, 
calls routine PRIN to process input in the intercontrol 
point buffer. 

PRIN does the following: 



a . 



b. 
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If last input in communication block not processed, 
try to schedule ITASK; otherwise continue at next 
step. 

If the transaction executive is not rolled in, call 
TRI to rol I it in. 
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c. Checks the data manager activity Limit (MDM) . If at 
Limit, then exit; else, continue. 

d. CaLLs RDCB. 

4. RDCB checks for command/ status message and branches to 
CSM. 

5. CSM (command/status message processor) does the following: 
a. Branches to terminaL Login on function code 3. 



b. CaLLs STST (search terminaL status tabLe) to find 
entry corresponding to the terminaL name. 

c. Checks for valid terminaL. If iLLegaL terminaL, set 
error code . 

d. Does an intercontroL point transfer to the time- 
sharing executive with a function code 2012B, the 
terminaL ordinaL, the terminaL name and the error 
code. 

e. If an error, clear intercontroL point buffer and exit 
to TSSC. 

f. Sets the Login fLag in the TST. 

g. BuiLds a new message in the intercontroL point buffer 
which is a system origin transaction, code CILOG, to 
inform ITASK of the Login. This is processed as a 
normal message input. 

h. Return to the inner Loop, TSSC. 
NAM TO TAF LOGIN 
The Login procedure to NAM is as follows. 

1. The transaction subsystem checks for supervisory 
messages from NAM in the TAFNAM communication routine 
NGL. 

2. When NGL detects any supervisory message (a flag is set 
in NSUP by AIP) it gives control to the TAF supervisory 
message processor (SMP). 

3. When SMP receives a connection request (CON/REQ) 
supervisory message it calls CRE to process the 
f o I Lowi ng steps . 

a. Match the terminal name specified by NAM to a name 
in the terminaL status table (TST). If no TST entry 
is found with a matching terminal name, reject the 
connection because of illegal terminal name. 

b. Check login flag in TST; if terminal already logged 
in, reject the connection. TAF allows only one 
connection per user name. 
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c. Put TST address and output block Limit in NCT entry 
word one . 

d. Save block size, hard wired line, device type, page 
width, and page length at terminal for ITASK. 

e. Send a connection accepted supervisory to NAM. 

4. When SMP receives a connection initialized (FC/INIT) it 
calls PCI to process the following steps. 

a. Set flag in TST to indicate terminal is logged in. 

b. Send a normal response supervisory message to NAM. 

c. Call routine PRIN to schedule ITASK with login 
function code and terminal information saved in step 
3.d. If ITASK is scheduled, it sends a READY, to 
the terminal. Otherwise, the supervisory message 
(FC/INIT) is queued and executed later by this 
routine unless the connection is broken or a network 
drop supervisory is received. 

INPUT MESSAGE SEQUENCE FOR TIME-SHARING EXECUTIVE TO TAFTS 
COMMUNICATIONS 

The time-sharing executive transfers messages to the transaction 
executive using SIC RA + 1 ' request . Up to 64 words may be 
transferred in to a buffer (referred to as the input buffer) at a 
t i me . 

The input buffer status word (word one of the input buffer) when 
input is a message is: 



t 

to 

wc 



59 



48 



38 35 



17 



I 







to 



wc 



m 

Set to indicate message input. Clear indicates 

command status message. 

Set indicates more input buf f ers (b lock) to follow 

for this message. Clear indicates last buffer 

(block) of this message. 

Set indicates a system origin transaction 

(originated by the transaction executive). Clear 

indicates a terminal origin message. 

Application character type. Used only for NAM. 

Originating terminal ordinal. 

Message word count including status word. 



When a message is too large to transfer to the transaction 
executive in one input buffer (block), it will be sent in 
multiple buffers. The m bit is used to flag this situation. 
The number of pots per input buffer and maximum number of 
buffers are parameters in the time-sharing executive. The 
transaction executive will assign a communication block to each 
input buffer and assign an input buffer (block) number to each 
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successive buffer received. The task will receive the data fro™ 
the first input buffer in its communication block and can read 
the rest with the LOADCB macro. 

Routine PRIN processes the input buffer. 

PRIN processes input and queues for ITASK. The following steps 

are performed. 

If routine PRIN is called by NGL, go to step 9. 



If communication blocks are available, continue; else, 
return to caller. 

If first word of input buffer is zero, exit. 
If TAF is rolled out, call TRI to roll in. 

Check MDM for zero (maximum number of data manager request 
in progress). If zero, exit. 

Call RDCB (read communication block) to transfer a 
transaction input from the input buffer to a communication 
block. 

a If bit 59 (command status flag) of first word of input 
buffer is set, continue; else, branch to CSM to 
process command status message. 

Record time of this input. 

Call FFCB to get a communication block. 

If no communication block available, exit. 

Validate terminal ordinal from input buffer. If 
terminal ordinal is zero, negative or beyond the table 
length, then increment counter of number of times 
input has been thrown away (this is a system bug), 
clear input buffer, release the communication block, 
and exit; else, continue. 

If bit 48 of input buffer word 1 set (system origin 
transaction) or bit 17 of TST entry word 2 clear 
(multiple input bit which when clear means first input 
block of a transaction input), continue else search 
communication blocks to determine the next block 
number for this partial transaction input. 

If last input block (bit 58 of input buffer word 1 
clear), increment transaction count in TST and 
continue, else set multiple input block flag in TST 
(bit 17 of TST word 2) and if first multi-block input. 
Set block number to one. 

Call routine FCB to do the following. 
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• If first input block, increment transaction 

sequence count and use new sequence number. 

• Format the communication block. 
I. User header contains: 

- Data base name 

- User area 

- Transaction sequence number 

- Terminal name 

- System transaction indicator 

- Multiple block indicator 

- Batch input indicator 

- Parity error indicator 

- Word count of input area 

II. System header contains: 

- CPU priority = 3 (packed format) 

- Terminal read and update securities 

- Communications block address 

- Terminal ordinal 

- TST address 

- Input block count 

III. The following words are cleared 

- Task list (word 3) 

- Dump parameters (word 4) 

- Call with return (word 6) 

i. Move message from input buffer to communications 
block message area with zero fill. 

j. If system origin transaction, exit. 

k. If terminal not in wait for input state (bit 59 of 
TST word 1 clear) or not last block of multiple 
input, then continue, request call routine RTK to 
rollin of task waiting for input. 

I. Put packed date and time in communication block. 

m. Call routine JOL to journal transaction. Code 3 if 
wait for input; code 5 if multi-block input; code 1 
if last of multi-block input or first of single block 
input. 

n. If first block of input, exit; else, replace 

communication block address of current block with 
address of first block and exit. 

If input buffer was not last of mult i-b lock input or 
input was in response to a wait for input, exit. 
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10 



11 



12 



13 



If no communication block was available, set overflow 
f lag and exit. 

Search for an open entry in ITASK (subcontrol point 1) 
subcontrol point table (word 4-CPACL) if found, continue; 
else, put communication block address in overflow flag 
and exit. 

Make entry in subcontrol point table status word with 
communications block address, initial load bit set and 
waiting for CPU bit set. 

Increment the communication block count by one in 
subcontrol point table. 

If ITASK is active (communication block in execution, word 
2 of SCP table bits 0-17 nonzero) exit. 

Call RCPT to request CPU for task. 

Set request CPU bit in CR for the subcontrol point. 



a . 
b. 



If someone has CPU (B2=0) or current transaction is 
higher priority, exit; else, branch to BNT. BNT 
assigns CPU to a different subcontrol point by setting 
B2 to the start of the subcontrol point area and B7 to 
the address of the subcontrol point table and exits. 



14 



PRIN exits 



INPUT MESSAGE SEQUENCE FOR NAM TO TAF COMMUNICATIONS 

TAF uses the application interface program (AIP) to communicate 
with NAM. Currently, TAF uses parallel mode which enables it to 
continue execution after making the network request. Routine 
NGL periodically checks for the completion of a request and then 
processes the next statement of the request. The following are 
the possible sequences of input from the network. 

1. Supervisory message. The supervisory message processor 
(SMP) is called to perform required actions. 

2. Small message (MSG) input block. Routine NIT requests 
a communication block and performs a NETGETL to place 
the message into the communication block. Routine PLB 
is called to format the communication block. A task 
waiting for input or ITASK is scheduled. 

3. Large MSG input block. Routine NIT gets an 
undeliverable block and calls routine PBU. PBU requests 
NCBN-1 communication blocks, chains them together, and 
performs a NETGETF request. PLB is called as in step 2. 
If the communication block is not available, the 
terminal is put in TEMP OFF state until communication 
blocks are available. 
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4. First small BLK input block. Since the message size 

cannot be determined, PFB reserves NCBN-1 communication 
blocks and chains them together. Routine PSI is called 
to process and pack all inputs in communication blocks 
until the last MSG block. Then PSI calls PLB to 
process all inputs as in step 2. If not enough 
communication blocks are available the terminal is 
placed in a TEMP OFF state and the first communication 
block is pointed to by the network communication table 
(NCT) terminal entry until communication blocks are 
avai lab le . 

5. Subsequent BLK input blocks. NCBN communication blocks 
must be reserved and chained together. All inputs are 
packed into communication blocks until the last MSG 
block. PLB then is called to process all inputs as in 
step 2 . 

TASK EXECUTION FOR INPUT MESSAGE 

Either TSSC is returned to or is eventually branched to. The 
assumption is that a return is eventually made to TSSC after 
the CPU is assigned to ITASK. 

1. Abort flag will not be set. 

2. Not a start after recall. 

3. No communication block has been loaded for task. 

4. Find status word in subcontrol point table for 
communications block waiting for CPU. 

5. Set up control point area. 

a. (CB1C) = word 1 of communication block system header, 
b! (CB2C) = word 2 of communication block system header. 

6. Put status word address (in subcontrol point table) in 
word 2 of subcontrol point table. 

7 This is system task so put communication block system 

header words 1 and 2 in task field length address 111B an 
d 112B. 

8. Move user communication block to task field length 
starting at 111B. 

9. Since this is an initial load 

a. Set up exchange package using information in 
subcontrol point table. 

b. Clear initial load bit in subcontrol point table 
status word. 

c. Set time slice and RA+1 request limits to default. 
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Clear the folowing: 



Terminal output count 

Rollout threshold terminal word count 
Task RA, RA + 1 , and RA + 2 branch count 
Outstanding data manager request count 
Total data manager request count 



Set data base name task is validated for. 



10. Exchange the subcontrol point. 

At this point, the communication block is in 
111B and ITASK is ready to start execution. 



ITASK's FL at 



DOWNLINE MESSAGE PROCESSING 



inal which originated the 



A task may send messages to the term 
transaction (the originating terminal) or another terminal 
validated for the same data base as the originating terminal 
using a subcontrol point RA + 1 request (CIT, function code 0) . , 
FORTRAN or COBOL task may use the SEND interface deck to format 



the RA+1 request 



SEND interface deck is loaded and linked with the 

entered with a return jump and 



The 

application task. It is 

following parameters. 



the 



Message address 

Message length (embedded in COBOL parameter) 

Terminal (optional) 

Cease flag (optional) 

Sequence flag (optional) 

Block return flag; applies only when NAM is used 

Status return flag; applies only when NAM is used 



An RA+1 request is formatted as follows. 



59 



47 



41 



RA+1 



CTI 



35 



29 



fnc 



17 



addr 



fnc Function code (SEND=0) 
addr Parameter list address 
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The parameter List at Location addr is formatted as -follows 



59 53 47 



29 



addr+O 



+ 1 



+ 2 



flags 







fwa of message 



17 








number of words 
in message 



application block header 



flags Each bit defined as follows: 

Bi t Desc ri pt ion 

59 if set, sent to terminal name in addr+1; 
else send to originating terminal 

58 Task cease requested, if set 

57 Output flag; if set, more sends are to 
f o I low 

56 Return application block number 

55 if set, send must wait for block to be 
delivered to terminal 

54 if set, user supplies application block 
header 

The trailing characters not specified in the character count of 
the message are cleared before the RA+1 request and restored 
after the request. Also, a zero word is added at the end of 
the message if the above process does not guarantee 12 bits of 
zero. It is restored after the request is processed. 

The task RA+1 request gives the transaction executive control in 
SRTN after the XCHN6E macro. The following steps are performed. 

1. If exit flag set, check error conditions and process them, 
else cont i nue . 

2. If RA+1 request present, continue else go to TSSC. 

3. Clear RA+1 , increment RA+1 count and if limit exceeded, 
go to error processor. 

4. Branch to CTI processor (for SEND). 

CTI will process the RA+1 request using the following procedure. 
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1. If illegal function code or parameter address out of 
bounds, go to error processor, else continue. 

2. Branch to SEND code (based on function code in RA+1 ) . 

3. Next. 

4. If message is to originating terminal, set message sent 
flag in communication block system header. 

5. If terminal is not originating terminal: 

Find the terminal in terminal status table. 
Validate that task data base is the same as the terminals 
or that the task is validated for all data bases. If not, 
go to error processor. 

6. If no terminal exists, go to error processor. 

7. If terminal not logged in go to error processor. 

8. If word count is negative, zero or greater than or equal 
to MAXWS (64), go to error processor. 

9. Add current message word count (from subcontrol point 
area) to tasks output to date word count. If greater 
than MAXTO, go to error processor. 

10. If message is ahead (at a lower address) of the 
communication block, go to error processor. 

11. If NAM is used for terminal communications go to step 41. 

12. The time-sharing exeutive is used for communications to 
termi nals . 

13. Get rollout word count (ROWC) from subcontrol point area. 

14. If not first send and rollout word count plus current 
word count are greater than rollout threshold (R0LT0), 
then set the rollout threshold bit in the SIC buffer 
header word (bit 58). 

15. Update rollout word count (ROWC) in subcontrol point area 
to include current count. 

16. Save word in task ahead of the message and replace it 
with the SIC buffer header word. 

17. A SIC request is formatted (see CPUMTR listing for 
details on how to use SIC requests). A copy of the RA+1 
request is stored in the task's RA+1 without the buffer 
address being biased by the task's RA. 

18. If other task(s) are waiting for SIC (TPLW nonzero), go 
to 20. 
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19. Issue SIC request and wait for completion. 

20. Restore word used by header of buffer. 

21. Check SIC status. If not successful or if other task(s) 
are waiting, go to 26. 

22. Clear task RA+1 . 

23. If this was a retry, remove next waiting task subcontrol 
point table address from RSIC word is subcontrol point 
area and place it in TPLW word. TPLW is checked in TSSC 
and if enough time has elapsed, it will reenter the SEND 
routine at step 33. 

24. If CEASE requested, go to CEASE entry point in SCT. 

24.1 If rollout threshold bit is set, go to 30, else continue. 

25. Go to task slicing loop TSSC. 

26. Save SIC buffer header word in subcontrol point area word 
RCLA and CEASE flag in RCL. 

Set time since last rejected SIC to current time. 

27. Link tasks waiting for SIC request via TPLW and task word 
RSIC. Go to routine DCPT to drop CPU for task. 

28. Routine DCPT clears control point bit in CPU switching 
, word CR. 

29. If CR zero (CPU idle), clear B2 and B7 and exit to inner 
loop, TSSC, else continue. 

30. Using mask in word after CR (set at the end of TMDC), 
search 

A. Lower control points 

B. Then check the lower control points for highest 
CPU priority task. Note that the mask in the word 
after CR ensures that tasks of equal priorities 
are time sliced one after another. 

31. The highest priority task is then activated by setting 
(B2) to subcontrol point area address, (B7) to subcontrol 
point table address, and exiting to TSSC. This point is 
reentered from TSSC after a specified time since last SIC 
attempt. TPLW contains the address of the tasks 
subcontrol point table. 

32. Set the recall bit in word 2 of the subcontrol point 
table. Put step 33 in recall address. Request CPU for 
whichever subcontrol point adds request bit in CR and 
assign CPU to task if no one has CPU or this task is 
greater or equal priority. The return is to TSSC. This 
point is entered by recall processing in TMDC. 
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33 



Reinitialize to try SIC request again 



o Set cease flag. 

o Load SIC request from task RA+1 

o Put SIC buffer header in buffer 

o Set retry flag 

o Go to step 19 

34. If data manager requests are outstanding, jump to recall 
routine with step 34 as reentry. 

35. If no rollout table entry is available or the prior 
rollout is not complete, jump to recall routine with step 
36 as reentry. 

36. Compute rollout time based on line speed and amount of 
output . 

Build event descriptor word. EVTO is terminal rollout 
event (20020--0) . Build roLLout parameters as follows. 



59 



53 



35 



trf 



current time + 
rollout time 



trf Timed rollin flag 
Set time to leave task in core to zero. 

37. Clear rollout word count in ROWC in subcontrol point area 
with si gn bi t set . 

38. Enter event roll routine to rollout task. 

39. The time-sharing executive will issue a SIC status 
command message when the end of the previous output to the 
terminal is about to be reached. This is processed by CSM 
and a task with event EVTO is made a candidate for rollin. 

40. The task is rolled in by the scheduler and started up to 
continue processing. 

41. The following steps process the terminal output to NAM. 

a. If terminal logged in, go to step c. 

b. If send with recall, return terminal not logged in 
status to task and go to task switch routine TSSC; 
else, abort the task. 

c. If terminal does not have a down line stop status, go 
to step e. 
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If task send with recall, return down-line stop to 
task and go to task switch routine; else, abort the 
task. 

If terminal has send with recall active or the 
previous network request is not yet complete, go to 

step z. 

If outstanding output block is zero, go to j. 
If task call send with recall, go to step z. 
If there is no block limit, go to step k. 

If output does not exceed block limit, go to k; else, 

go to step f. 

Set recall bit (TNSR) in NCT, if needed- 
Format application block header (ABH); if task does 
not supply ABH, use default values for ABH. Put ABH 
in NCT. 

Update outstanding output block counter (TNBO) in NCT. 

a. If break flag is set, send a reset supervisory 
message to NAM. 

Do a NETPUT. Call routine PPM to check network 
status. If the request is complete, go to step n; 
otherwise TAF returns to step n later. 

If send with cease, exit to cease routine SCT2. 

If send with no recall, exit to TSSC. 

Compute time that block must be delivered by using 
current time plus installation assembly wait time and 
put time in task system area. 

Set task return to step x upon rescheduling. 

If message is less than installation def i ned limi t, 
go to step aa. 

If task has data manager activity or rollout table is 
unavailable, go to step aa. 

Set rollout bit TNSE in NCT. 

Use ACN and ABN to identify the event and exit to 
rollout routine. 

If there is a supervisory message in NCT, copy the 
supervisory message to the task status address, clear 
the recall field in the NCT, clear the supervisory 
message from the NCT, and exit to the task switching 
routine. 
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X . 

y 

z 
aa 



If the time for the block 'delivered supervisory 
message has passed, return a block not delivered 
supervisory message to the task status address, clear 
the recall field in the NCT, zero number of 
outstanding output blocks in the NCT, and exit to the 
task switching routine. 

Task must continue to wait; set task return address. 

Prepare entry registers for SND and go to step a. 

Let return address be step y upon task rescheduled. 

Put task in recall and exit to executive recall 
rout i ne. 



DATA MANAGER COMMUNICATION 

TAF communicates to all data managers CTAF, TOTAL, and TAF CRM) 
in the same manner. The general procedure is as follows (refer 
to f i gure 16-1 1 ) . 

1. A task makes a data manager RA request. 

2. CPU monitor detects the request and gives control to 
TAF. 

3. TAF determines the type of RA request and jumps to the 
appropriate data manager processor (TAF, TOTAL, or TAF 
CRM). 

4. The data manager RA processor enters the task request 
into the appropriate data manager input queue (TAF, 
TOTAL, or TAF CRM) . 

5. Periodically TAF initiates the data manager which 
removes entries from the input queue and performs the 
requested function. The TAF CRM interface routine 
performs all the necessary record and file locking. 
The TAF CRM request is mapped to the corresponding CRM 
request. The CRM data manager accesses the data base 
and transfers blocks to/from the buffer pool. The user 
data is passed from/to these buffers to/from the 
working storage areas at the task subcontrol point. 

6. When the data manager completes the request, the user 
function is entered in the output queue. 

7. Periodically TAF examines the data manager output 
queues. The data manager output queue processor 
removes the entry from the queue and schedules the task 
for execut ion. 
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TAF DATA MANAGER 

The general steps for processing a TAF data manager request are 
as f o I Lows . 

1. The task begins running and makes a data manager RA+1 
request. 

2. CPU monitor gives request to TAF. 

3. The TAF executive puts data manager request into data 
manager queue. 

4. The data manager is called periodically if activity has 
oc cur red . 

5. The data manager converts key to PRU address. 

6. The records in central memory are checked to see if any 
records contain desired key. Assume record not in 
central memory. Records held by task are paged out of 
memory. 

7. A read is initiated for the record. An entry for the 
request is made in the input/output active data manager 
queue. 

Upon next entrance to the data manager, a check for I/O 
complete is made. 

8. Assume I/O is complete and no errors have occurred. An 
entry is put in the active reentrant request data 
manager queue. 

9. Upon next entrance to data manager, a check is made on 
reentrant request data manager queue. A jump is made 
to the appropriate processor. 

10. The element is converted from format of record to the 
format of user task area and is moved to the task. 

11. A data manager complete entry is made in the data 
manager output queue. 

12. When the data manager has completed one pass of the 
data manager input queue, control returns to the TAF 
executive. 

13. The TAF executive processes the data manager Output 
queue. The CPU is requested for the task. 

14. The TAF executive does an exchange with the task. The 
task has the element. 
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TAF CRM DATA MANAGER 

The steps for processing a TAF CRM data manager request are as 
f o L lows . 

1. The TAF executive in routine AAM places the task 
request in the AAMIQ input queue. 

2. TAF CRM is called periodically if any activity has 
occur red . 

3. TAF CRM tries to process any requests with active 
i nput /output . If the data record has not been 
retrieved another seek is done and the next request is 
processed. If the data record has been retrieved, the 
record is moved from the TAF buffer to the task buffer. 

4. An entry is made in the AAMOQ output queue. The TAF 
executive examines this queue after TAF CRM returns to 
the executive and starts up the task. 

5. After processing all active requests, the AAMIQ input 
queue is processed. 

6. If the requst needs to lock a record, the record is 
locked. If a lock cannot be obtained, all locked 
records for a transaction are -released. 

7. The CRM request corresponding to the TAF function is 
done. If the request does not require i nput /output , an 
entry is made in the AAMOQ output queue; otherwise the 
first SEEK request is initiated. 

8. Control is returned to the TAF executive after one pass 
is made of the input queue. 



INTERNAL TASK XJP TRACE 

As an aid for locating a problem if TAF aborts as a result of a 
task RA+1 call, the internal task XJP trace is provided. 
Information related to the task being processed is stored in a 
circular buffer within the field length of TAF by the trace. If 
TAF aborts, the contents of this buffer can be examined if a 
dump of TAF has been taken. 

Upon return from subcontrol point activation in SRTN, a call is 
made to the internal task XJP trace processing subroutine TXT 
under one of the following conditions. 

• If an RA+1 request from the task is present 

• If an error flag is set and the error is not time-slice 
exceeded or the error is time-slice exceeded and the 
total number of time-slices allowed has been exceeded 
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Each time it is called, TXT sets up and stores one packet of 
task-related information into the circular buffer PBUF. The 
length of a trace packet is defined by the symbol ITTPL as being 
four words. The format of each trace packet is as follows. 



59 



word 1 



47 



35 



tef 


tid 


(B2) 


(B7) 


ra+ I 


cb fwa 


sptw 



tef 2000B plus the error flag returned from 
subcontrol point activation 

tid Task trace packet identifier (set to zero) 

(B2) Start of the system area of the task 
currently selected for CPU assignment 

(B7) Start of the subcontrol point area of the 
task currently selected for CPU assignment 

ra+1 Contents of RA+1 of the task field length 

cb fwa First word of the communications block 
kept in the system area preceding the 
R A of the task 

sptw Third word of the subcontrol point table for 
the task 

The FET for the internal trace buffer PBUF is found at the 
symbol INTRACE. The length of the buffer is defined as 30*ITTPL 
or 170B words. It contains enough space to store the last 30 
packets of four words each which were produced. The information 
is not written to any external file. 
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INSTALLATION MODIFICATION OF INTERNAL TRACE 

The following are provided as guidelines should an installation 
wish to either make modifications to certain aspects of the 
internal XJP trace or write its own internal trace code to trace 
other events in TAF. The internal XJP trace processing 
subroutine TXT is based upon these guidelines and not following 
them may cause TXT to work improperly. 

1. Since the code for the internal trace is executed 
frequently, it should be simple and fast, essentially 
st raight li ne. 

2. PBUF is intended to be the circular buffer used for 
storing all internal trace packets; those generated by 
TXT and also those generated by any installation code. 
PBUFL, the length of the buffer, is defined as the total 
number of packets that can be stored in the buffer at 
one time multiplied by ITTPL, the packet size (four 
words at present). For example, by default PBUFL is 
defined as 30*ITTPL. This provides enough space to 
store up to 30 trace packets of four words each. 

3. All trace packets, from both TXT and installation code, 
are the same length. This length is defined by ITTPL 
as four words. If the length is changed, ITTPL must be 
redefined. Only lengths of four or more words are 
acceptab le . 

Although all packets are of the same length, the number 
of words of trace information stored in each may not be 
equal to ITTPL. This situation can occur if, for 
example, an installation routine stores trace packets of 
five words each and TXT stores four. ITTPL will have 
been redefined as five. The last words of the packets 
stored by TXT should then be ignored. This unused word 
occurs because of the way TXT updates the IN pointer 
(refer to guideline 4). 

4. The IN pointer of the INTRACE FET is updated so that 
the following are assured: 

• All packets are of length ITTPL. 

• The circularity of the buffer is maintained. 
That is, when the IN pointer equals LIMIT, set 
the IN pointer equal to the beginning of the 
buffer. 

It is strongly suggested that an installation use the 
code in TXT as a guide for updating the IN pointer. 
TXT calculates the value of the IN pointer for storing 
the next packet by taking the value of the IN pointer 
for storing the first word of the current packet and 
adding ITTPL to it. 
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5 In order to identify the type of event being traced, a 
unique task trace packet identifier TID should be 
assigned for each event and be stored into bits 4f 
through 36 of the first word of each packet. This 
field is set to zero to identify those packets stored 
for the task XJP trace. 



The TID can also serve as an indicator to the number 
words in the packet that contain trace information. 
(This pertains to the situation where some packets 
contain less than ITTPL words of trace information.) 
Refer to figure 16-11 for more information. 

TAF TROUBLE-SHOOTING 

The following steps provide an orderly process for trouble- 
shooting when errors occur in TAF. 

1 Examine the TAF dayfile. Setting sense switch 6 
assures that the job dayfile is printed upon 
termination. 



of 



2. 



3. 



4. 



5. 
6. 

7. 
8. 



Insert DMP statements after the EXIT statement in the 
TAF procedure file. 

Examine the exchange package. Register B2 usually 
points to the context block (task system area) for the 
currently executing subcontrol point. Register B7 
usually points to the subcontrol point table for the 
currently executing task. 



Bit 46 



45 



Examine word CR where set bits indicate which 
subcontrol points are candidates for execution 
corresponds to subcontrol point 1 (ITASK), bit 
corresponds to subcontrol point 2, and so on. 

Examine word RCR where set bits indicate which 
subcontrol points are in recall. 

Examine word VCPA to find the location of the 
subcontrol point tables. Examine the subcontrol point 
tables indicated by register B7, word CR, and word RCR. 

Check the communication blocks indicated by subcontrol 
point tables to examine terminal input. 

Check other communication blocks that are being used. 
Word VCBRT gives the first word address of a map for 
the communication blocks. Zeros in bits 47 through 
indicate communication blocks in use. Word VCBSA gives 
the first word address of the start of the 
communication blocks. 
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59 



47 



35 



PBUF 



not used 



not used 



not used 



not used 



END OF BUFFER 
LIMIT 



not used 



not used 



ITTPL is defined as 5. 



If TID is 0, it is a task 
XJP packet; only the first 
four words are used. 



If TID is I (installation 
code), it is an event B 
trace packet; all words 
are used. 



If TID is 2 (installation 
code), it is an event C 
trace packet ; only the 
first three words are used. 



Figure 16-11- Trace Buffer Layout 
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9. Check the task system area (context block) of 

subcontroL points that are active or are in recall. 
The task system area is at RA minus 100B from the RA 
given by the subcontrol point table. 

10. The following words are of special interest in the task 
system area. 



Word 

XJPC 

LRA1 

RCL 

RCLA 

ERRC 

DHEC 



Desc ri pt i on 
Task exchange package 
Last RA + 1 cal I 

Address for recall 

Parameters for recall 

Task error code (zero if a valid error 
code) 

Data manager error code 



11. Examine the rollout table. Word VROLT gives the 
location of the rollout table allocation map. Zeros in 
the map in bits 47 through indicate active rollout 
table entries. The rollout table follows the mapping 
words . 

12. Examine terminal input as follows. 

• For communications with the time-sharing 
executive examine word INRB 

• For communications- with NAM examine file 
ZZZZZDN, the AIP debug file. This file is 
produced by using library NETIOD to obtain 
the AIP. 

13. Examine the journal files using TDUMP. Useful 
information may also be found in the J0UR0 FET located 
at symbol PJRNL. 

14. Examine the data manager input/output queues DMIQ/DMOQ. 
The FETs for these queues are at symbols DI and DO. 

15. Examine the data manager buffer status table (BST) to 
find current records. Active BST entries are given by 
a map pointed to by the word VBSTR. 

16. Examine the internal trace information in the buffer 
PBUF. The FET for this buffer is found at symbol 
INTRACE. 
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LIBTASK UTILITY 

The LIBTASK utility is used to create a new Library, add new 
tasks to an existing Library, replace tasks on an existing 
Library, and compact an existing Library by removing inactive 
records. Tasks may be added or replaced while the transaction 
subsystem is running, as tasks are added as a new file at the 
end of the library. The library is multifile in format. The 
transaction executive attempts to read a new library directory 
if the LIBTASK control statement contains a TT parameter. 
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ified while the trasaction subsystem is 
wants the new directory used, the user 
f the LIBTASK user are passed to the 

for validation. This is done by 
mmunication, which is also used to check if 
stem is running if the CR or PR option is 

the first USER statement in the job must 
rform intercontrol point communication. The 

error message and does not update the 
s not validated (refer to section 20 for 
g user validation). The task binaries to 
must be in absolute overlay format and 

in length. The first word address must be 
The format is that produced by the 



The main flow of LIBTASK is shown in figure 16-12. 
PRS-PRESET ROUTINE 

PRS cracks the control statement and sets up for the main 
program. Error checking is performed on control statement 
parameters. If any error occurs, LIBTASK aborts with an error 
message. All files are initialized and input directives are 
processed by LIBTASK (default value is used if an error occurs in 
a directive). Routine PRS is flowcharted in figure 16-13. 
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Figure 16-12. LIBTASK Main Flow 



60454300 B 



16-71 



PRS 



ARG 

process 

control 

parameters 




ERC 




check illegal 

parameters 

combination 



diagnostic: 

ILLEGAL 
CONTROL CARD 



( abort J 




Figure 16-13. PRS - Preset Routine 
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PCR - PROCESS CREATE OPTION 

LIBTASK creates a task Library from the specified binary file 
and adds the task Library directory (TLD) to the end of the task 
Library as the foLLowing iLLustrates: 



LGOB 



task 



task 2 



task n 



new task I ibrary 



task 1 


task 2 


• 

• 


task n 


TLD 



Task Library Directory 

The TLD consists of a four-word header and a three-word entry 
for each task in the Library, both of which are constructed 
automaticaLLy by LIBTASK. The directory is the Last record in 
the task Library. 

The format of the header which incLudes the date and time of the 
Last modification of the Library is as foLLows. 



59 



47 41 



7700 



TLD 



0003 
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bpt Relative word in directory where tasks are 
added after creation of library. 

nsy Number of system origin tasks. 
The format of a directory entry is as follows. 



59 54 




IS 




7 12 5 


name 




ep 




da 


fl 




bp 


mp 


P 


reserved 




ql 





name 

ep 

da 

f I 

bp 

mp 

P 



ql 



Task name, left-justified,, zero filled 

Entry point address 

Mass storage index 

Field length required for task 

Begi nni ng priority 

Maxi mum priority 

Each bit defined as follows: 

B i t Desc ri pt ion 

59 System task (special system 
p ri vi leges) i f set 

58 Destructive code (reload binaries 

after use) if zero 

57 Memory-resident task if set 

56 ECS-resident library copy if set 

55 Task ON if zero 

54 Task active if zero 

53 So li c i t i nput 

Maximum number of transactions to queue for 
this task 
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The default values for the directory are as follows. 
Beginning priority (bp) is 20B 
Maximum priority (mp) is 40B 
Queue limi t (q I) i s 3 
Task is mass storage resident 
Task is not a system task (p bit 59 zero) 
Task code is nondestructive (p bit 58 set) 
Task is not a memory resident task (p bit 57 zero) 
Task is not an ECS resident task (p bit 56 zero) 
Task is ON (p bit 55 zero) 

Task is not logically deleted (inactive) (p bit 54 zero) 
Task does not solicit input (p bit 53 zero) 
Figure 16-14 illustrates the flow for routine PCR. 



PTT - PROCESS TELL TAF OPTION 



The task library can be updated while the library is attached by 
TAF. The transaction executive attempts to read the new library 
directory if the LIBTASK control statement contains a TT 
parameter. The format of the task library is shown in figure 



P 
16-15. 



Figure 16-16 illustrates the flow for routine PTT. 



PIT - PURGE INACTIVE TASKS 

Inactive tasks can be removed from the task library when the 
library is not attachd by TAF. LIBTASK also removes inactive 
tasks when the purge option (PR) is specified on the LIBTASK 
control statement. The format of the task library is shown in 
figure 1 6-1 7 . 

Figure 16-18 illustrates the flow for routine PIT. 
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PNP - PROCESS NO PARAMETERS 

The user does not have to specify the CR, PR, or TT parameters. 
If P=Q, LIBTASK performs a creation run. If the file specified 
by N is attached by TAF, LIBTASK processing is the same as the 
TT option with sorted directory at the end of the Library file. 
When P is nonzero and N file is not attached by TAF, the PR 
option is assumed. 

Figure 16-19 illustrates the flow for routine PNP. 
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C PCR J 



RBF 

read and 

create task 

library 



SDR 



sort 
directory 



CDR 



copy directory 

to task 

library 



( return J 



Figure 16-14. PCR - Process Create Option 
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OLD 



task 



task 2 



task n 



TLD 



LGOB 


task 2 


task 4 


task n+l 



NEW 



task 1 


task 


2 


task 


3 


task 4 



task n 



TLD 



EOR 



task 2 



task 4 



■* 



Mile 1 



task n+l 



TLD 



file 2 



* Task 2 and task 4 in file 1 will not be used by TAF 



Figure 16-15. Library Format 
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RBF 



read binary 

file, copy to 

library 




te 
17 


f . , ,, 

II 
^F 


\ 


' 


[ return J 



Figure 16-16. PTT - Process Tell TAF Option 
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file 1 < 



file 2 



file 3 { 



OLD tosk library 



task 1 



task 2 



task n 



TLD 



EOR 



task 2 



TLD 2 



EOR 



task 1 



task 2 



TLD 



-L_l 1 



-7 - r 



.j 



_L 



- J 



NEW task library 



task 1 



task 2 



task n~1 



task n 



TLD 



LGOB 



task n-l 



__J 



Figure 16-17. Task Library Format 
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(3 



SAT 

select 
active 
tasks 



RBF 



read binary 

file, copy to 

library 



SDR 



sort 
directory 



COR 



copy 
directory 



( return J 



Figure 16-18. PIT - Purge Inactive Tasks 
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Figure 16-19. PNP - Process No Parameters 
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PRODUCT SET SUPPORT MONITOR REQUESTS 

A subset of the standard NOS monitor functions is supported by 
TAF in order to allow product set binaries to function in the 
transaction environment. The monitor functions are processed 
with recall, even if not specified by the task. 

SFP DOO REQUEST 

The purpose of the SFP D00 function is to retrieve message texts 
that are stored on an STEXT record residing on a system file. 
Many of the product sets install in such a manner that the error 
texts which the object libraries use to issue dayfile messages 
at abnormaL termination are resident on a system file and must 
be retrieved by the D00 processor. This technique allows the 
field lengths of the various products to be reduced by the sizes 
of the individual texts. The format of the D00 call is 
described in section 30. 

Since the transaction environment does not support the concept 
of dayfiles for tasks, the option to transfer the error message 
that might be generated by a task to the transaction executive 
dayfile is not supported. Tasks with this option are aborted by 
the executive if they issue a D00 request. 

Excessive use of the DOO request by tasks can result in a 
performance degradation of the TAF subsystem. DOO is 
implemented as an overlay to SFP which requires that the call be 
made with autorecall. Thus, the task request is actually made by 
the TAF executive, resulting in the inoperativeness of the entire 
TAF subsystem for the duration of the call. Therefore, a site 
should not use this function to reduce the general size of tasks 
issuing error messages by installing an error text on the system 
file and then accessing it through DOO. 

CPM (27B) - GET JOB ORIGIN 



s can determine whether or not they are running in 
tion environment with the get job origin CPM function 



Product sets 

the transact . xoat 

A transaction origin job returns a job origin type of TROT 



TROT is a pseudo-origin in that the operating system is not 
involved in TAF internal scheduling or processes. TROT is 
useful for differentiating task and TAF executive CM and CPU 
usage and in determining execution-time environments. 
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The format of the call is as follows. 



59 



41 



23 17 



CPM 







27B 



addr 



Upon completion, location addr has the following format. 



59 



addr 



TROT 



END - END CPU PROGRAM 

The END request CENDRUN macro) allows a termination path through 
the current object libraries without explicitly issuing a TAF 
CEASE function. This function is mapped into a CEASE in the 
function handler. The format of the END call is as follows. 



59 



41 



END 



There is no response to the END function, since the CPU cannot 
be returned without a job step advance or task switch. 
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ABT - ABORT CPU PROGRAM 

The ABT request (ABORT macro) maps into a CEASE with abort by 
the function handler. The format of the ABT request is as 
f o I Lows . 



59 


41 


ABT 


• 





There is no response to the ABT function. 
SCT - BUFFER WAITINP 

The ACCEPT COBOL verb is supported by this function, rather than 
by CIO. The format of the SCT call is as follows. 



59 



SCT 



41 



23 17 



IIB 



addr 



addr 



CTI - TPSTATUS 



FWA of buffer to pass the terminal input to 
The usual FWA of load is not the default 
residence for the buffer which is the 
argument to this function. 



The terminal control attributes of the two support teleprocessors 
use the CTI monitor function which allows a task to determine 
which it is running under in order to issue the appropriate SEND 
requests. The format of the CTI call is as follows. 



59 


41 


23 


17 


CTI 





26B 


addr 
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addr 



Address to receive the active teleprocessor 
c ode 



TLXTP 
NAMTP 



CTI - BEGIN 

The CTI BEGIN function returns the communication block which 
contains the primary terminal transmission. The user may 




f o I lows . 



59 



41 



23 17 



CTI 



2IB 



addr 



addr 



FWA of 
block. 



buffer to receive the communication 



be 



Tasks that use this feature must dec are . e . " /^ TASK 
solicited communication block requests with the *SC LIBTASK 
request. Also, if an *SC task is invoked through the CALLRTH 
request, a BEGIN request must be issued by the calling task in 
order to obtain the communication block which is the usual data 
communication mechanism between two tasks. 
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BATCHIO 



17 



INTRODUCTION 

The BATCHIO subsystem processes data transfers between the unit 
record equipment (card reader, CR; card punch, CP; and printer, 
LP) and the operating system. BATCHIO basically performs the 
following functions. 

• Reads cards from the card reader, creates the input file, 
and enters the job into the input queue. 

• Locates files in the print queue, locates a free printer, 
and prints the file on the printer. 

• Locates files in the punch queue, locates a free card punch, 
and punches the file on the card punch. 

• Processes the DSD operator commands issued for the specified 
file currently being operated on at a given buffer point. 
Each device is entered into the available equipment table, 
TAEQ. The index to each entry is the buffer point number. 
That is, the first entry is buffer point 1, the second entry 
is buffer point 2, the last device is n. All information 
passed to and from BATCHIO for DSD/1DS is done using the 
logical equipment number. 

The subsystem consists of three PP programs and one control 
poi nt (figure 17-1 ) . 
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© 



BATCH 10 FL 








177B 



BATCHIO control 
point idle, FL is 
200B. 




110 



© 




TAtQ 




CR 


^ 










• 
LP 


) 










CP 







110 is recalled (RLPW 

word in control point area) and begins 

scan of available unit record equipment. 



59 53 47 



© 



17 11 5 



BATCHIO 
cp 




110 finds a card- reader ready and 
calls 1CD for processing. 



1CD calls QAP to build an input file entry and 
write the data to the disk via CIO. 



Figure 17-1. BATCHIO Overview 
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© 

BATCHIO FL 




1CD reads the card reader, writes the 
data into a CM buffer,and calls CIO to 
write the CM buffer to the disk. After 

the file has been completely read, 1CD calls 

QAP who in turn calls DSP to put the file into the input queue. 



59 53 47 



FNT 



FST 




11 



job 
org 



INFT 



cp=0 



110 calls QAC to find an output 
queue entry and then calls 1CD. 



Figure 17-1. BATCHIO Overview (Continued) 
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© 

BATCHIO FL 




1CD calls QAP to create a banner page 
(QAP calls OBP) in the CM buffer. 



BATCHIO FL 



© 




1CD reads the rest of the file to the CM buffer via CIO 
and prints the data on the printer. 

© 

BATCHIO FL=200B 



1CD completes and drops? 
BATCHIO is now idle. 



Figure 17-1. BATCHIO Overview (Continued) 
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BATCHIO CONTROL POINT 




device is assigned one FET and one buffer. 

used and the buffer size ranges from 420B words for punch files 

up to 2020B words for 12-bit ASCII code print files. 



BATCHIO COMMUNICATION 

Much of the intercommunication among 110, 1CD, and QAP occurs in 
two areas of central memory: 

• The BATCHIO control point area 

• The BATCHIO field length 

In the BATCHIO control point area, the locations normally used 
for the control statement buffer CCSBW) are not needed for that 
purpose by BATCHIO. Hence, these locations are used to store 
buffer information (BFCW=CSBW) and are referred to as the buffer 
point area. Each line printer, card punch, and card reader use 
two locations in the buffer point area in the following format. 



59 


4 


47 




35 ; 


Zb 


\( 


n 


D 


filename 


eq 


re 


or 


idmc 


demc 


mparaml 


mparam2 


mparam3 



f i lename 

eq 

re 



or 



Logical f i le name 

Equipment number (EST ordinal) 

One of the following: 

• Repeat count, if no operator request 

• Request parameter, if operator request 
Operator request: 

None 

1 End 

2 Repeat 

3 Suppress 
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4 Rerun 

5 Hold 

6 Continue 

7 BKSP PRU 

10 BKSP record 

11 BKSP f i Le 

12 Skip PRU 

1 3 Ski p record 

14 Skip f i Le 

idmc I display message code 

demc Dayf i Le/error Log message code 

mparaml Message parameter: 

• Repeat count (LP and CP only) 

• End count (LP and CP only) 

• Channel number 
mparam2 Message parameter: 

• Driver address 

• Printer error count (LP only) 
mparam3 One of the following 

• Function code 

• Message parameter: 

- Funct ion code 

- Bytes remaining after an incomplete 
data transfer 

The buffer point area is referenced by the logical equipment 
number of the device from the I display when communicating with 
DSD. 

The BATCHIO field length also provides an area for communication. 
Each active device has a corresponding FET and buffer in the 
BATCHIO field length as follows. 
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The core Layout of the BATCHIO control point is shown in Figure 
17-2 



RA+O 
+ l 

+ 10 



+ 20 



+ 30 



+ 131 

+ 140 
+ 145 







DCWs 



driver request word 



available equipment table 



translation tables 



queue access parameter blockt 



CIO call block 



buffers 



DRQR 



TEQR 



CTIR 



QAPB 

CIOB 
BUFR 



t Built by 110 for QAC call to locate an unavailable qualifying 
file. 



Figure 17-2. BATCHIO Central Memory Layout 
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A driver control word (DCW) is used by 110 to determine how many 
copies of 1CD are active and how many requests (equipments) each 
one is currently processing. The DCW (one for each copy of 1CD 
that is active) are stored in reverse order beginning at RA + 7 
continuing through RA+2. Each DCW can support up to MEQD (10B) 
equipments. The DCW is reference by a DCW index which is the 
DCW position relative to RA; that is, the DCW at RA+7 has index 
7. The DCW has the following format. 



59 



41 



DCW 



1CD 







35 



23 



11 



DCW index 



requests 



Word DRQR (driver request) is used to communicate between 1CD 
and 110. DRQR is located at RA+10B and has the following 
format. 



DRQR 



59 



47 



DCW index 



EST ord. 



35 



buffer 
point 



23 



buffer address 



Buf f e rs 



59 



FET + O 
+ 1 
+ 2 
+ 3 
+ 4 
+ 5 
+6 
+ 7 

+ 13 



47 



35 



23 17 



11 







filename 



fnta 



bn 



cs 



fparaml 



es 



fparam2 



bf 



status 



FIRST 



IN 



OUT 



LIMIT 



cv 



ot 



userlim 



queue access parameter block 
(built for DSP when ready to queue a file) 



buffer 
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filename Logical file name 



status Fi le status 



FIRST Address of first word of buffer (relative 

to RA) 



IN 



OUT 



Next available address for entering data 
in buffer (relative to RA) 

Next available address for removing data 
from buffer (relative to RA) 



fnta FN T address 

LIMIT Last word address plus 1 of buffer (first 

word address of next FET and buffer, 
relative to RA) 

bn Buffer point number 

fparaml File parameter: 

• First track of dayf i le (LP only) 

• First card number of read sequence 
error (CR only) 

fparam2 File parameter: 

• First sector of dayf i le (LP only) 

• Punch format (CP only) 

• Record number of read sequence 
error (CR only) 

cv Count of V characters used (LP/PFC only) 

ot Ori gi n type 

cs Converter (6681) status 

es Equipment status 

bf BATCHIO flags 

userlim Maximum number of possible lines printed 
or cards punched (LP and CP only) 

Each buffer immediately follows its corresponding FET; that is, 
the first word address of the buffer is the last word plus 1 of 
the FET. Also, the next FET and buffer immediately follow the 
current buffer; that is, the first word address of the next FET 
is RA+LIMIT of the current FET. 
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BATCHIO OVERVIEW 

Routine 110 is a transient PP routine. It recalls itself by 

always copying its input register (IR) into the PP recall word 

(RLPW) before dropping or relinquishing the PP to another PP 
rout ine . 

If there are no outstanding requests, 110 reads and scans the 
available equipment table for ready devices (subroutine REQ) . 
When the scan has been completed, 110 recalls itself, if no 
equipment has been processed. 

If a card reader in ready status is found, a buffer is assigned 
for the equipment and a DRQR request for 1CD is initiated in 
BATCHIO's field length to process the card reader. If 1CD is 
active and is not already processing MEQD equipments, the active 
request count in the DCW is advanced by one. Otherwise, a DCW is 
set up to start up a new copy of 1CD (subroutines 3IA/ABF and 
3IA/ADR). 

If an unassigned card punch or line printer is in ready status 
and is ON, a QAC call is made to identify a queue file having the 
same external characteristics as the printer or punch. Routine 
110 recalls itself with the file requested flag set in the RLPW. 
QAC is loaded into this PP (subroutine SFF). 

When recalled, 110 detects the file requested bit and checks to 
see if QAC has completed and indicated a queue file to be 
disposed to the printer or punch (subroutine CFF). If a file is 
found, a buffer is assigned for the equipment and DRQR request 
initiated as is done for the card reader (subroutines 3IA/ABF and 
3IA/ADR). If QAC has not completed, 110 recalls itself. If QAC 
completes but no file is found or an error occurs, the scan of 
available equipments starts again. 



Rout in 
buf f e r 
unit r 
1 CD re 
i s det 
IIF) . 
cards, 
ent ry 
is ass 
i s the 
to rea 
( input 
QAP i s 
to ent 
f unct i 



e 1CD responds to requests that appear in DRQR and in the 

point words. Routine 1CD contains the drivers for all 
ecord equipments. If a card reader request is detected, 
ads one full buffer of cards (1020B words) or until EOR/EOF 
ected and calls QAP to process the input file subroutine 
Routine QAP calls overlay OVJ to process the job and user 
which must be the first two cards in the job deck. An FNT 
is made using the job name returned by OVJ and mass storage 
igned using MSAL if an input equipment was specified. CIO 
n called to begin writing the file. Routine 1CD continues 
d cards and transfers their images to the mass storage file 
file) via CIO. When the file has been completely read, 
called again to perform accounting of the cards read and 
er the file into the input queue via a DSP call (QAP 
on ACTF, subroutine ACT). 



If the request was for a printer or punch 1CD calls QAP to build 
the banner page (function GBPF, subroutine LPR) or lace card 
(function GLCF, subroutine LPH) and places it into the BATCHIO 
buffer. Routine 1CD then transfers data from the file into the 
BATCHIO buffer using CIO and prints or punches the file in the 
proper format. When the file has been completely printed or 
punched, QAP is called again to perform accounting of the lines 
printed or cards 
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punched and calls DSP to decrement the files repeat count if any 
(QAP function ACTF, subroutine ACT). 

After the equipment has completed its operation, 110 releases the 
BATCHIO buffer and may return the storage it required. 

BATCHIO MANAGER - 110 

Routine 110 is the executive routine for the BATCHIO subsystem 
and performs scheduling of all processes operating at the 
BATCHIO control point. These include the following. 

• Searching for the highest priority OUTPUT and PUNCH files 
(via QAC) 

• Checking for a ready status on any card readers, line 
printers, or card punches 

• Managing of buffer storage and allocating and deallocating 
central memory for the BATCHIO control point 

• Posting of error condition messages for any of the above 



The 110 call format is as follows. 

59 41 29 23^ 



110 



cpn 



rs 



11 



bn 



ab 



p Preset performed (bit 41=1 once preset is 

performed) 

cpn Control point number 

f File previously requested flag (bit 30) 

rs Release storage repeat count 

bn Buffer point number currently under consideration 

ab Active buffer count 

As 110 operates, it stores values in cells IR+2, 3, and 4, and 
when recalled IR+2, 3, and 4 are reset. On recall these cells 
contain the following. 

IR+2 File previously requested and storage release repeat 
count 

IR+3 Buffer point number 

IR+4 Number of buffers allocated (number of requests 
currently performing) 

When the operator command n.IO, AUTO., or MAINTENANCE, is sensed, 
DSD calls 1DS to initiate the BATCHIO subsystem (see subsystem 
initiation in Section 5). Routine 110 is called and checks the 
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p bit in the input register and if not set, calls the preset 

overlay 310. 

Routine 110 first checks DRQR. If DRQR is nonzero (that is, 
some copy of 1CD has not yet responded to the last request), 110 
processes error messages and checks central memory allocation. 
Eventually, DRQR becomes zero. The frequency of requests, 
versus the speed of unit record equipment, versus the speed of 
1CD responding, does not necessitate more than a one-word request 
stack. The time lost while 110 waits for 
neg li gib le. 



DRQR to clear is 



If DRQR is zero, 110 checks the input register for pending file 
requests. If a file request is pending, 110 checks to see if a 
file has been identified for disposal. If none is found, the 
file requested flag is cleared and 110 proceeds with the TAEQ 
scan. If a file is found, 110 requests a buffer for the file 
and requests 1CD. Line printer image memory is loaded by 110 if 
the equipment is a printer. If the file search done by QAC is 
not complete, 110 recalls itself. 

Routine 110 scans the TAEQ tables for ready and unassigned unit 
record equipment when no other requests are pending. If an 
equipment is found, it is processed according to its type. For 
card readers, 110 assigns a buffer and calls 1CD through DRQR. 
For line printers and card punches, 110 formats a QAC call to 
search the queue for the highest priority file having the 
external characteristics, forms code, and ID of the available 
equipment. The file requested flag is set to indicate the QAC 
call is being made and 110 recalls itself relinquishing its PP 
to QAC. 

If a 1CD request needs to be made, 110 checks the DC.W words for 
an active 1CD. If one is found and byte 3 (number of current 
requests active) is less than MEQD, 110 sets up the request in 
DRQR. Up to six copies of 1CD could be active at one time, 
depending on MXEQ, which is an assembled constant in C0MSBI0 and 
states the maximum number of equipments that can be active at 
once. Currently MXEQ is 24B, so the maximum 1CD copies is three. 
MXEQ is determined by the size of the control statement buffer. 
The buffer size is 50B words, and with two words per buffer 
point, this translates to a maximum of 24B equipments. 

If there are no copies of 1CD currently active, or the copies 
which are active have the maximum current requests MEQD, and 
this request brings the total current request to less than MXEQ, 
then 110 sets up the next DCW word, sets up the DRQR word, 
recalls itself, and calls 1CD into this PP. 

When 110 is recalled, it checks if scheduling has been disabled. 
If this disable bit has been set (bit 13 of INWL in CMR), 110 
does not schedule any new 1CD requests. It waits until all 
pending requests are complete, processes any error messages as 
they occur, releases buffers and all of central memory assigned 
to the control point, releases the control point, and then drops 
from the PP. If the disable bit is not set, 110 continues 
performing as above. 



Figure 17-3 is a flowchart of the main loop routine 110. 
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jump to processor: 
LPP = line printer 
CPP = card punch 
CRP = card reader 



• 1 
*2 
*3 
*4 
*5 

• 6 



*7 



IR+1 = display code for 110, P, CP number. 

CMR cell INWL (bit 13) 

Is IR+4 nonzero? 

Messages are IDLE and xx BUFFERS ACTIVE. 

Check RA+DRQR. . 

RA+TEQR read EST and check each equipment for status in TEQR 

table; if some equipment needs to be processed, then (A) 

nonzero, CEQ)=equi pment number, (ES-ES+4)=EST entry, and 

(IR+3)=equi pment index. 

IR+2, bit 6 set if file previously requested. 



Figure 17-3. 110 - BATCHIO Main Loop 



60454300 A 



17-13 




3IA 

w assign 

* buffer 



C A0R ) 



Figure 17-3. 110 - BATCHIO Main Loop (Continued) 
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CPR 



check any 
pending 
requests 



CSR 



release 
storage 




<£) 



recall X n0 ^ 
requested ^ * 



no /^ 
» ( BCMJ 



place 110 IR 
into the recall 
register RLPW 



/dppV 



FTN 



DPPM 




+/err\ 



/3IA/PEF 



process 

error 

flags 



Figure 17-3. 110 - BATCHIO Main Loop (Continued) 
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The following paragraphs describe 110 subroutines and overlays. 



CFF - CHECK FOR FILE 

CFF reads the buffer point table CTAEQ) and the EST entry for 
the buffer point in question (from IR+3). CFF then reads the 
QAC parameter block from BATCHIO's field length. This block is 
found at location QAPB (RA+131B) and is seven words in length. 
If the request has completed, (bit of QAPB is 1), the file 
requested flag is cleared from the input register (bit 30; IR + 2, 
bit 6). If the request completes with errors, the error code is 
retrieved from bits 17 through 12 of QAPB and is returned to the 
caller. If the request completes successfully, the file's FST 
is read and CFF returns to its caller. If the request is not 
complete, this status is returned to the caller. 

CPR - CHECK PENDING REQUEST 

CPR reads DRQR and if a request is present, the control word for 
the driver is read. If 1 CD is not active, then 3IA is loaded 
and the driver is assigned. 



CSR - CHECK FOR STORAGE RELEASE 

CSR releases BATCHIO field length not needed due to a buffer 
point completing its activity. Field length management is only 
done every five (5) calls of CSR. The number of CSR calls 
kept in the lower 6 bits of IR+2. Storage space is 
from the last buffer in use to the current FL; that 
are any free buffers beyond the last buffer in 
is returned. The new, buffer count is set into 
includes all active and inactive' buffers up to 
i n use . 



i s 
re leased 
is, if there 
use, their space 
IR+4, which 
the last buffer 



MSG - PROCESS CONTROL POINT MESSAGE 

MSG issues messages to MS1W of the control point area. Two 
messages are issued: IDLE if no buffers are active; or nn 
BUFFERS ACTIVE where nn is the number of buffers defined. Some 
of the nn buffers may not be in use, but cannot be released 
since a buffer beyond them is still active. 



REQ - REQUEST EQUIPMENT 

REQ scans the buffer point table (TAEQ) checking the status of 
the unass'igned unit record equipment listed. If the equipment is 
off, the OFF message pointer is set for display on the I display. 
If on, the equipment is requested (REQM) and statused. If it is 
not ready, it is released (DEQM) and the NOT READY message 
pointer is set for the I display. The starting position of the 
TAEQ search is saved in IR+3 so that the search moves circularly 
through TAEQ as ready equipment are processed. 
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SFF » SEARCH FOR FILE 

SFF formats a call to PP routine QAC to search the FNT for a 
queue file having a given set of characteristics. The QAC call 
block is written into BATCHIO's field length at location QAPB, 
110 is put into recall by writing the input register into RLPW 
file requested flag set (IR+2, bit 6), 



P 
with the 

is written into this PP's input register, 
through a call to PPR. 



QAC 



and the QAC call 
is then loaded 



3ID - 110 PRESET BATCHIO 

Overlay 3ID writes the jobname BATCHIO into control point area 
word JNMW and sets the CPU priority to 1 and queue priority to 
BIPS via the RPRM monitor function. The initial field length of 
200B words is requested using the RSTM function. 

The EST is scanned for valid unit record equipment, namely card 
readers (CR), card punches (CP), and line printers (LP, LR, LS, 
and LT). If a valid unit record peripheral is found, a buffer 
point entry is made in BFCW and in the TAEQ table. If no 
equipment is found, the message NO EQUIPMENT AVAILABLE is issued 
and BATCHIO terminates. If more than 24B peripherals (defined by 
symbol MXEQ) exist, the diagnostic NOT ALL EQUIPMENT SERVICEABLE 
is issued and only the first 24 equipments are used. The input 
register has bit 43 set to indicate preset has been performed. 

The 64 character set is used as the default character set . If 
63 character set is used (IPRDECK parameter CSM=63), the 63 
character set conversion is entered in conversion tables 
C0MT6DP, C0MT9DP, C0MTDA8, C0MTDP6, and C0MTDP9 such that 
a colon is changed from display code 00 to 63, 00 becomes a 
space, and percent is dropped. The conversion tables are then 
written into BATCHIO's field length beginning at word CTIR and 
3ID returns to the main program. 



The TAEQ (table of available equipment) has a one to one 
correspondence with the buffer point table entries and has 
f o I lowi ng format . 



the 



number of entries 


est 


type 


est 


type 


• 
• 
• 


• 
• 
• 


est 


type 



TAEQ 

buffer point 1 

buffer point 2 



buffer point 24 (if any) 
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type 



est 





1 

2 


Printer (LP, LR, LS, 
Punch (CP) 
Printer (CR) 


ST 


ordinal of equipment 



LT) 



3IA - 110 AUXILIARY SUBROUTINES 

Overlay 3IA contains various subroutines used by 1T0 to perform 
buffer point management. 

ABF - Assign Buffer 

ABF assigns a buffer to a particular equipment. Subroutines EFT, 
EFP, EBP, and FFB are called to accomplish the assignment. 

ADR - Assign Driver 

ADR calls the combined driver 1CD into an available PP or this 
PP if none is available as necessary. If 1CD is already active 
and is not full (driving less than 8 equipments), the equipment 
being assigned is added to the current DRQR requests. 



ANB - Add New Buffer 

ANB sets the FIRST and LIMIT values for a newly established 
buffer. 



EBP - Enter Buffer Point Information 

EBP sets the initial repeat count, job name, and equipment 
number in the buffer point word for display by DSD on the I 
display. 



EFP - Enter File Parameters 

For output files, EFP extracts parameters such as user limits, 
dayfile address (if any), and other file characteristics from the 
QAC parameter block. The control values contained in FET+5 and 
FET+6 are initialized at this time; these values are the buffer 
number, dayfile track (if any), punch format, job origin, and 
limit va lues . 



EFT - Enter FET Information 

EFT initializes the buffer FET. FET+0 receives the file name 
(two blanks if input file) and completion status, and IN and OUT 
are set equal to FIRST. The address of the FNT is set in the 
LIMIT word. 
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FFB - Find Free Buffer 

FFB scans the buffer points for an available CM buffer of the 
size required for the equipment making the request. If a free 
buffer of the correct size is found, it is used. Otherwise, a 
storage increase of the CM buffer size required is made. If the 
storage is made available, the new CM buffer is added (by ANB) at 
the end of the current CM buffers. 

The CM buffer space required is 1020B to 2020B words for a line 
printer, 1020B for a card reader, and 420B words for a card 
punch. 

3IB - LOAD IMAGE MEMORY 

Routine 3IB contains the code required to load print train image 
memory for defined Line printers. 

The print train image memories supported in NOS are the 596-1, 
596-4, 596-5, and 596-6. The image memories are contained in 
overlays named 5Ix where x is a character that defines the type 
of train. The data in the image memory overlay is specified by a 
macro that defines the actual print slug. Macros SLUG and ESLUG 
are defined in 3IB and specify the number of characters on each 
slug and the characters themselves. The following image memories 
are defined, 



Image Memory 

5IE 
5IG 
5IH 



Print Train 

596-1 

596-4, 596-5 

596-6 



The print train image memories apply to all 580 printers. 

Extended array mode is set at the time image memory is loaded. 
Therefore, all data sent to the line printer is interpretted b; 
the controller as one 8-bit character per byte. 

3IC - ERROR PROCESSOR 

Overlay 3IC contains subroutines to process hardware status 
errors and to requeue files attached to BATCHIO. 
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BATCHIO COMBINED DRIVER - UP 

The BATCHIO driver, 1CD, can drive up to eight devices of three 
types Cany combination). These three types of devices are: 



580 

3446/415 

3447/405 



Printer 
Card Punch 
Card Reader 



Some functions, such as accounting, are performed by calling SAP 
Mass storage transfers are performed by CIO. 

Each of the drivers use the conversion tables that reside in the 
BATCHIO field length. The conversion tables required by the 
devices are loaded into 1CD from CTIR as needed. 



PRINTER DRIVER CHARACTERISTICS 

Line spacing is normally done in the AUTO EJECT mode. That is, 
creases in the paper are skipped via the 3555 or 580 automatic 
line spacing. Thus, it is necessary for AUTO EJECT to be 
deselected to use format channels to advance from prior to bottom 
of form to beyond top of form. An example of this is the typical 
NOS format tape which has only one hole in channel 6, thus 
providing an eject of up to two pages in order to ensure all 
banner pages are printed correctly. Deselection of auto eject 
mode on a 580 results in deselection of eight lines/inch if 
previously selected. 

The first character of the print line controls the optional 
formats. The print line, therefore, consists of up to 136 
characters. The first character is recognized as a format 
control character and is never printed. If the first character 
is not a valid format control character, it is ignored and 
treated as if it were a blank. 

The format control characters, their functions, and the number 
of lines charged are listed in table 17-1. 

Any format control other than Q, R, S, and T are processed once 
for the line printed. 
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TABLE 17-1. FORMAT CONTROL CHARACTERS 



Character 



Funct ion 



Li nes 
Charged 



C 

D 

E 

F 

G 

H 

Q* 

R* 

S* 

T* 

V 


1 

2 
3 

4 
5 
6 

7 
8 

+ 



nt 
nt 
nt 
nt 
nt 



Skip to format channel 6 after pn 

Skip to format channel 5 after pri 

Skip to format channel 4 after pri 

Skip to format channel 3 after pr 

Skip to format channel 2 after pr 

Skip to format channel 1 after print 

Suppress auto eject 

Set auto eject 

C lear 8 li nes/ i nch 

Set 8 Lines/inch 

Eject page and change PFC image 

Space 1 line before print 
Eject page before print 

Advance to last line of form before print 



nt 
nt 
nt 
nt 



Skip to format channel 6 before pri 
Skip to format channel 5 before pri 
Skip to format channel 4 before pri 
Skip to format channel 3 before pri 
Skip to "format channel 2 before print 
Skip to format channel 1 before print 
Suppress space before print 
Space 2 lines before print 
Suppress space after print 



4 

3 

3 

2 

2 

1 









PL6L/ 
PL8L 

2 

PL6L or 
PL8L 

PL6L/2 

4 

3 

3 

2 

2 , 

1 

1 

3 

1 



*Q, R, S, and T ignore the remainder of the line. 
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TABLE 17-1. FORMAT CONTROL CHARACTERS (CONTINUED) 



Character 



Funct ion 



Li nes 
Charged 



Space 
Other 



No Line control 

No Line control - character printed 
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CARD PUNCH DRIVER CHARACTERISTICS 

Hollerith cards are punched from a line consisting of up to 90 
characters. However, only the first 80 characters of the line 
are actually punched. The display code to 026/029 conversion is 
accomplished by a display code to binary column image conversion 
in the driver. These column images are then punched in binary 



Col 


umn 


1 




2 




3 - 


77 


78 




79 


- 80 



a 
i 
mode . 

Binary data are punched in the following format. 

Desc r i p t i on 
Word count and binary card indicator (79) 
Binary data checksum modulo 4096 
15 central memory words of data 
Blank 
24-bit binary card sequence number 

Absolute binary data are punched 16 central memory words per card 
with no special punches. 

End-of-record cards contain a 7/8/9 multi-punch in columns 1 and 
80, and the remainder of the card is blank. 

End-of-file cards contain a 6/7/9 punch in columns 1 and 80, and 
the remainder of the card is blank. 

End-of-information cards contain a 6/7/8/9 multi-punch in 
columns 1 and 80, and the remainder of the card is blank. Cards 
offset are as follows. 

• The end-of-information card 

• All end-of-record cards 

• A card on which a compare error is detected and the 
following card (these two cards are repunched until no 
error is detected) 



CARD READER DRIVER CHARACTERISTICS 

All cards are read in binary mode. Coded cards are converted to 
display code by the driver. Up to 80 characters may be 
transferred to the CM buffer. The mode of the coded conversion 
can be changed as follows. 
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Mode Change Indicator 

26 or 29 punched in columns 79 and 80 

26 or 29 punched in columns 79 and 80 

26 or 29 punched in columns 79 and 80 

No punch in column 2 indicates 026 mode; 
9 punch in column 2 indicates 029 mode. 



A mode change is in effect until changed. Default keypunch mode 
for a job is defined as an installation parameter (KEYPM) . 

For the 5/7/9 card, the following are valid conversion mode 
punches in column 2: 



Punch 



B lank 



Desc ri pt ion 



4/5/6/7/8/9 



Bi nar 

bi nar 

mu It i 

with 

consi 

7/8/9 

conve 

these 

cards 

chang 

af f ec 

78. 



y cards 
y data, 
punched 
6/7/9 m 
s ts of 

card a 

rs ion. 

cards 

are in 

e of 02 

t the i 



mus 
An 

i n 
ult i 
a ca 
nd t 

A 2 
(or 

026 
9 mo 
nput 



t con 
end- 
co lum 
punch 
rd wi 
he 6/ 
6 pun 
on a 

mode 
de . 
mode 



026 



029 

Literal input; cards are read in binary 
format with no conversion or checking 
until a card which is identical in all 80 
columns is read 

form to the above specification for punched 
of-record consists of a card with 7/8/9 
n 1. An end-of-file consists of a card 
ed in column 1. An end-of-i nf ormat ion 
th 6/7/8/9 multipunched in column 1. The 
7/9 card signal input keypunch mode 
ched in columns 79 and 80 of either of 
job card) indicates that the following 

A 29 in columns 79 and 80 indicate a 
Anything else in columns 79 and 80 do not 
and are ignored, as are columns 2 through 



The call to 1CD is as follows. 



59 



IR 



1CD 



41 



35 



23 



cp 



DCW index 



cp 



Control point number 
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1CD - BATCHIO PERIPHERAL DRIVER 

Routine 1CD does not use any mass storage drivers. This allows 
it to use the area of PP resident reserved for the mass storage 
driver and high core reserved for driver recovery processing for 
translation tables and data. The translation tables are loaded 
when needed beginning at location MSFW. 

The preset routine moves subroutines WNB, CEP, RBB, WBB, and the 
channel table TCHS to PP resident following the translation 
table area, sets the default keypunch mode from IPRL, and sets 
the control point number for CIO and QAP service calls. 

After preset (and as long as 1CD is at this PP), the main loop 
(manager) checks DRQR for nonzero. If it is nonzero, the DRQR 
DCW offset is compared to the 1CD DCW index in IR+2. If they do 
not match or DRQR is zero, 1CD assesses the status of its active 
requests. As a request goes inactive, 1CD decrements the active 
request count in its appropriate DCW word. If the active 
request count goes to zero, 1CD cleans its respective DCW word 
and drops. 

If the DRQR DCW offset is equal to this 1CD, 1CD starts up the 
proper driver and increments its active request count in its 
approrpiate DCW word. The manager is flowcharted in figure 
17-4. 

Routine 1CD can service up to eight devices by each device 
sequentially gaining control of 1CD to perform processing. The 
relative location buffer in 1CD associated with each device and 
the CM buffer in the BATCHIO FL (which includes a FET and a QAPB) 
associated with each device, preserve the required information 
for 1CD to process this device. 

After each call to CIO or QAP, 1CD jumps to its main loop. The 
drivers can be processing many requests simultaneously and 
are honored in sequence by 1CD. The limit of MEQD (currently 
10B) is all one copy of 1CD can process 
drive each device at top speed. 



and still continue to 



The layout of 1CD is shown in figure 17-3.1. 

A relative location buffer is reserved for all eight possible 
devices. The data buffers are each 141 PP words in length and 
are shared by all devices serviced by that copy of 1CD. The 
number (n in figure 17-3.1) of such data buffers is determined 
by the space available in 1CD (n 'is currently 4). 

A data buffer is assigned to a particular device by subroutine 
ADB (assign data buffer) and released by subroutine RDB (release 
data buffer). These data buffers are reserved for a minimum 
period of time. A relative location buffer is associated with 
each device, while a data buffer is assigned (ADB) and released 
(RDB) by the reader, punch, or printer driver one or more times 
during the I/O process. 



60454300 B 



17-25 



MSFW 



PPFW 



conversion table area, 
WNB, CEP, RBB, WBB 
routines (moved here 
by preset) 



MGR 



subroutines 



LPD 



CPD 



CRD 



subroutines 



relative location buffer 1 



relative location buffer 2 



relative location buffer 8 



data buffer 1 



data buffer n 



Main routine 



Drivers 



Buffers 



Figure 17-3.1. 1CD Layout 
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preset 




save (A), 
program address, 
clear retry count 



PSE 



pause 



I 



read DRQR 



SEA 



set 
equipment 
assignment 



UVIGR2) 




request \ no 
(1R+2) 4= > »— * 



yes 



last 
buffer 
point 



no 



clear driver 
control word 



jump to 
not ready 
processor 




yes 



reset to 

beginning 

of table 



1 





-HMGR5 



DPPM 



drop PP 




reset program 

address, 

A register 



f return ) 



y — *TpprJ 



Figure 17-4. 1CD Manager 
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set equipment, 
set busy, 
return from CM BR 



read FET 



read buffer 
point word 



PMR 




no 




POF 



y es / process 

^operator request 



ZT 



process 
message request 




set file busy, 

set QAC 

block busy 



3 




Figure 17-4. 1CD Manager (Continued) 
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DSD OPERATOR REQUEST 

When DSD senses a BATCHIO operator request, it places the request 
in the buffer point word for the equipment through a call to 1DS. 
(If BATCHIO is not active, these commands are illegal.) 

Routine MGR in 1CD checks the buffer point area words of 
the equipments it is currently processing. If a request is set 
and the buffer is not busy, it calls the processor for the 
request. If the buffer is busy, the request is ignored until 
the buffer becomes available. 

The DSD buffer point commands are processed by 1CD as follows: 



Command 



END. 



REPEAT. 



SUPPRESS 



RERUN. 



STOP. 



CONTINUE 



Significance 

Set EOI status in buffer and set buffer 
empty. Print files with dayf i les present 
have their day file printed. If there are 
no repeats specified, QAP is called to 
perform the accounting for the operation. 

Advances repeat count by the number 
specified in the request. Repetition on 
card readers is ignored. 

Suppress toggles the suppress flag and is 
only processed for line printers. 
Suppression means that carriage control is 
i gnored . 

For line printers and card punches, a QAP 
call is issued (function RQFF) to requeue 
the file. For card readers, RERUN is 
i gnored . 

The hold flag is set for line printer; it 
is ignored for card equipment. Stop 
suspends printing. 



The stop flag is cleared and printing 
allowed to resume. 



1 s 



BKSP. 

BKSPF. 

BKSPRU 



SKIP. 

SKIPF. 

SKIPRU 



Backspaces print file the 

specified number of records 

(BKSP), files (BKSPF), or PRUS (BKSPRU) 

A QAP call is issued (function PORF) to 

position the print file. 

Skips forward on the print file 

a specified number of records 

(SKIP), files (SKIPF), or PRUs (SKIPRU) 

A QAP call is issued (function PORF) to 

position the print file. 



A message is issued to the system and control point dayf i le 
showing the parameters in the buffer point word. This is done 
QAP (function PDMF) . 



by 
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The following paragraphs describe 1CD subroutines. 

SEA - SET EQUIPMENT ASSIGNMENT 

SEA is called on each DRQR request to initialize the parameters 
used in processing that request. SEA sets the equipment number, 
buffer point address, buffer address, program address, 
conversion mode, equipment type, channel, and connect code; 
initializes the buffer status; clears the message request, 
controller busy retry count, data transfer error retry count, 
function reject retry count, busy return, and end/repeat flags; 
updates the equipment count in the input register; and clears 
the driver request. 

POF - PROCESS OPERATOR FLAG 

POF interrogates the operator request in the buffer point word 
and jumps to the processor for the particular operator function. 



LPD - LINE PRINTER DRIVER 

LPO is the driver for the Line printer 
through the following phases. 



The driver passes 



Ini t i ali'zat ion 

Load buffer 

Process format control 

Pri nt li ne 

Post print 

In the initialization phase, various flags and counters are 
initialized and QAP is requested to format the banner page 
(function GBPF) . 

In the load buffer phase, if the hold flag is set, the busy 
return status is set and the manager is called. If there is no 
hold condition, the line to be printed is read from the buffer 
in central memory to the data buffer in 1CD. As the line is 
read into the data buffer in 1CD, it is converted to 12-bit 
ASCII code if the print file is not already 12-bit ASCII code. 
If the print file is already 12-bit ASCII code, no conversion is 
necessary. A call to ADB was made previously to assign a data 
buffer. 

In the format control phase, if the supress flag is set or the 
format control character (first character of the line is blank), 
the line is printed. If the control character is nonblank, 
subroutine SPC (process space control) is called to perform the 
proper spacing and to charge for it. If the control character 
is Q, R, S, or T, no line is printed and phase 1 is reentered. 
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In the print line phase, the Line is printed without printing 
the format control character. A call to ROB is made here to 
release the data buffer. 

In the post print phase, the line count is advanced and a check 
is made to determine if the user limit for the number of lines 
allowable has been exceeded. 



CPD - CARD PUNCH DRIVER 

The card punch driver includes the following phases. 

• Initialization 

• Load buffer 

• Punch card 

• Check previous card 

In the initialization phase, the proper 026 or 029 conversion 
mode is selected and QAP is called to format the lace card 
(function 6LCF). The remaining phases are duplicated for binary 
or coded cards. A call to ADB is made here to assign a data 
buffer. 

In the load buffer phase, the EOR, EOF, and EOI status of the 
buffer is detected to determine if the special ending cards need 
to be punched. The card buffer is filled from the buffer in 
central memory by binary or coded reads. If a checksum for the 
binary card is required, it is generated at this time. 

In the punch card phase, the card is punched in binary format 
from the card buffer. The previous phase has prepared the data 
to be punched in binary mode (for the controller) so that the 
card punched has the proper system coded or binary specification 

In the check previous card phase, the punch status is 
interrogated to verify that the data has been punched correctly. 
If an error has occurred, a COMPARE ERROR message is posted and 
the card repunched with offset. 



CRD - CARD READER DRIVER 

The card reader driver has the following phases. 

Initialization 

Check mode of card 

Process card 

Dump buffer 

Store IN and update record count 
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In the initialization phase, record and card counts are 
initialized and default conversion mode is selected. 

The next phase checks the mode of the card. A call to ADB is 
made here to assign a data buffer. All cards are read in binary 
mode. If cards are being read in literal input mode, processing 
is transferred to the literal input processor. If not literal 
mode, the first column of the card determines whether the 
processing continues with the binary or coded processors. 

For coded card processing, the process card phase converts from 
binary to display code using the appropriate conversion table. 
Once the card has been converted, the dump buffer phase is 
entered and the data is copied to the central memory buffer. 



For binary card processing, the process card phase checks for 
special format CEOR/EOF with conversion mode specified), or 
literal input. The checksum for the binary card is generated. 
If the checksum is correct, the dump buffer phase is entered and 
the data copied to the central memory buffer. If the checksum 
does not agree, the operator is directed to reread 3 cards. If 
the cards are out of sequence, status is recorded in the FST so 
that the job is aborted when initiated by 1AJ. An appropriate 
diagnostic is issued under these conditions. 

For literal input, the data is taken as is and is sent to the 
central memory buffer. An EOI terminates literal input. 

The final phase advances the IN pointer, advances the card count 
and record count (if needed), and returns to the check mode of 
card phase. A call to RDB is made to release the data buffer. 



ACT - PROCESS ACCOUNTING INFORMATION 

ACT requests that QAP format an accounting message 
record operation performed (function ACTF). 



for the unit 



CIB - CHECK INPUT BUFFER 

CIB determines whether data has filled the buffer for a card 
reader. If the buffer is being written for the first time, a 
QAP call is made to initiate the input file. Otherwise, a CIO 
call is made. 



COB - CHECK OUTPUT BUFFER 

COB determines whether there is data in the buffer available 
be written to the line printer or card punch. COB transfers 
control to the EOR and EOF processors if that status was 
encountered. If the buffer is empty, it is filled by a CIO 
call (function 600 - READEI for line printers or function 10 
READ for card punches) . 



to 
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CPS - CALL PP SERVICE PROGRAM 

CPS formats calls to QAP and CIO to request the services the PP 
routines provide for 1C0. The function is set in the first word 
of the buffer FET. A QAP or CIO call is then formatted for the 
buffer. A PP is requested via the RPPM monitor function. If no 
PP is assigned, the previous status is reentered into the FET. 
Otherwise, the FET remains active and the function is completed 
by QAP or CIO. 

CUL - CHECK USER LIMIT REACHED 

CUL compares the current lines printed or cards punched values 
against the user limit values that were passed in the FET when 
the file was initiated by QAP. These limit values are obtained 
from the file's system sector wherein they are stored when the 
file is disposed to the queue. A call is made to QAP (PLEF) to 
terminate the buffer with the LINE LIMIT EXCEEDED (for printers) 
or LIMIT (for punched) messages to notify the user that the limit 
has been reached. 



PMR - PROCESS MESSAGE REQUEST 



PMR makes a QAP call (function PDMF) to process 
associated with a particular driver operation. 



a message 



RCB - READ CODED BUFFER 

RCB translates coded data from the central memory buffer into 
the proper character representation for printing or punching. 

TOF - TERMINATE OUTPUT FILE 

TOF terminates active output. If there are no repeats specified, 
control is transferred to subroutine TOP. If repetition is 
specified, the repeat count is decremented in the bufferpoint 
word. Accounting for the printing or punching are performed 
prior to the call to TOF; hence, the file is rewound and driver 
initialization phase reentered if repeat counts are present. 



TOP - TERMINATE OPERATION 

TOP causes the file to be dropped by a CIO close unload function 
(170). The buffer point word is reset for the equipment, the 
first word of the buffer FET is cleared, the number of equipment 
being processed by this copy of 1CD decremented, and the 
equipment released. 
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QAP - BATCHIO AUXILIARY PROCESSOR 

Routine QAP is called by 1CD to process several functions. The 
function codes (defined in COMSBIO) and their processors are: 

Description 

Process dayfile message 

Initiate input with write 

Initiate input with write EOR 

Initiate input with write EOF 

Channel error cleanup 

Process operator request 

Requeue file 

Load user image to 580 PFC 

Generate banner page 

Generate lace card 

Process user limit exceeded 

Process accounting 

Processors IIF, LPR, PLE, and PDF are contained within QAP, 
while the majority of the other processors call QAP over ays LPH 
<3BC>, ACT C3BA), POR C3BD), CEC C3BE), LPM (3BB), or PFC C3BF). 



Symbo I 
PDMF 


Code 
400 


Processor 


PDF 


WTIF 


410 


IIF 


WRIF 


420 


IIF 


WF.IF 


430 


IIF 


CECF 


440 


CEC 


PORF 


450 


POR 


RQFF 


460 


CEC 


PFCF 


470 


LPR1 


GBPF 


500 


LPR 


GLCF 


510 


LPH 


PLEF 


520 


PLE 


ACTF 


530 


ACT 



The call to QAP has the following format. 

59 41 35 24 17 

IR 




O 



addr 



cp 
addr 



Control point number 
Address of the FET 



The function code is contained in byte 4 of the first word of 
the FET. 
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The following paragraphs describe QAP processors and subroutines 
IIF - INITIATE INPUT FILE (WTIF, WRIF, WFIF) 



IIF b 
exami 
has r 
has n 
estab 
enter 
mass 
devi c 
using 
the s 
niach i 
PDTL) 
ca rds 
OVJ i 



ui Ids 
ne th 
ead t 
ot ye 
li she 

the 
stora 
e spe 

the 
ystem 
ne ID 
- CI 

read 
s wri 



a ske 
e firs 
he fir 
t been 
s the 
name o 
ge. I 
ci f i ed 
AMSM f 

secto 

(MISS 
is t 

to ma 
tten b 



leton system sector and then calls OVJ to 

t two control cards read by 1CD. Routine 1CD 

st block of cards into the buffer, but a file 

initiated to hold them. Routine OVJ 
name of the input file and OBF is called to 
f the input file into the FNT, but not assign 
IF assigns the mass storage equipment to the 

in MSAL or chooses any mass storage device 
unction. The FNT entry is then transferred to 
r, along with the file ID (DISS through DISS+1), 
), and creation date and time (CDSS, read from 
hen called into this PP to begin writing the 
ss storage. The system sector built by Q A P and 
y CIO. 



LPR - LOAD PRINT DATA (GBPF, PFCF) 

LPR checks the equipment type for a PFC printer. If this is the 
case, overlay 3BB is executed to load the PFC memory. Otherwise, 
overlay OBP is called to format the banner page. Routine OBP 
builds the banner page from information contained in the system 
sector and stores it in the buffer starting at FIRST. The IN 
pointer is set to the end of the banner page. After the banner 
page has been put in the buffer, LPR returns and. drops QAP. 



Over 

If t 

load 

para 

sys t 

the 

to t 

spac 

not 

oper 

(CHE 

ALI6 

must 

pri n 



lay 
he r 

a u 
mete 
em d 
prop 
he 5 
e co 
equa 
ator 
CK*I 
NMEN 

ent 
ting 



3BB is called to process a load of the 580 PFC memory, 
equest in the FET is PFCF, overlay 3BF is executed to 
ser supplied PFC image. Otherwise, a space code 
r is extracted from the FET. This value maps to a 
efined PFC image contained in overlay 5BA or 5BB. When 
er PFC image overlay has been loaded, it is transmitted 
80. A check is then made to determine the single line 
unt to a 6/8 line coincident point. If the space count is 
I to one, the paper alignment is in question. The 

is notified of this condition via the B display 
* DISPLAY) and the I display message (CHECK PAPER 
T) and the printer is placed in hold status. The operator 
er CONTINUE, xx. (xx is the equipment number) to begin 
. Control is returned to LPR to generate the banner page. 



Overlay 3BF is called to process a user supplied PFC image as 
defined by the current print line (S) in the buffer, prefixed 
with the V carriage control character. IF the user is not 
validated to use this feature, or if an error is detected in the 
PFC image, the print job is aborted. If the priner is not a PFC, 
the OUT pointer in the FET is advanced over the line (S) 
containing the PFC image and control is returned to 1CD. 
Otherwise, the user supplied PFC array is loaded to the printer 
using subroutines defined in overlay 3BB. The OUT pointer is 
advanced and control returns to 1CD via BCAX. 
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TPF - TERMINATE PRINT FILE 

TPF terminates a print file when its Line limit has been reached 
The message LINE LIMIT EXCEEDED is printed and then the dayfile, 
if one exists, is printed. 

PDF - PROCESS DAYFILE MESSAGES (PDMF) 

PDF formats and issues to the dayfile various messages for 1CD. 
These messages include hardware error messages and messages 
associated with DSD operator requests. 



PLE - PROCESS LIMIT EXCEEDED 

PLE reads the FNT to determine the file type. If it is a P r ] nt 
file, TPF is called. If the file is a punch file, LPH is called. 

ACT - ACCOUNTING (ACTF) 

Overlay 3BA is called to do summary accounting of unit record 
activities. The accounting messages are formatted and issued to 
the account dayfile for output (print, punch, and plot) files. 
DSP is called to enter an input file into the queue. For input 
files, the DSP call parameters select queuing (even if job card 
error), routing to the input queue, returning an error code, and 
routing to the central site. 

For print and punch files, the repeat count is set, error codes 
are returned, the deferred route bit is set, and FNT address are 
specified in the DSP call. 

PHD - GENERATE LACE CARD (GLCF) 

Overlay 3BC is called to load the initial punch data. If the 
user limit on the number of cards punched has occurred (function 
PLEF), the card LIMIT is written to the buffer with an EOI (1030) 
status. If limit has not occurred, the banner card of the job 
name is formatted into the buffer beginning at IN. The IN 
pointer is set to the next position and LPH returns and drops 
QAP. 

POR - PROCESS OPERATOR REQUESTS (PORF) 

POR loads overlay 3BD to process directives for BATCHIO entered 
through the operator's console. The following requests are 
processed. 
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Funct ion 


BKPO 


BKRO 


BKFO 


SKPO 


SKRO 


SKFO 



Descr i pt ion 



Backspace 
Backspace 
Backspace 
Skip PRUs 
Skip records 
Skip files 



PRUs 

records 

files 



CIO Funct ion Used 

44 
640 

640 level 17 
600 
240 
240 level 17 



Operator requests that do not require file manipulation are 
handled within the driver (1CD). 

Overlay 3BD contains subroutines that perform skipping and 
backspace CIO functions on the buffer as necessary to properly 
position the file. The proper function code, level number, and 
number of records or files are set into the input register and 
CIO is called into this PP. 



CEC - CHANNEL ERROR CLEANUP (CECF) 

CEC loads overlay 3BE to cleanup after repeated channel errors. 
Input files are dropped using a CIO close unload function (170) 
Output files are requeued through DSP calls. Faulty equipment 
is turned off with the appropriate error message (EQUIPMENT 
TURNED OFF) issued. 



BCAX - EXIT 

BCAX is the exit address for BCA. The function is completed, 
buffer status updated, and PP dropped. 



ERROR PROCESSING 

The majority of the error processing done by BATCHI0 routines 
involves hardware malfunction. Hardware malfunction includes 
channel error processing and bad system sector processing. 

The following channel errors are detected. 

• Connect reject 

• Funct ion re j ect 

• Transmission parity errors 

• Incomplete data transfer 

• 6681 function timeout 

• Equipment function timeout 
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When these errors are detected, the output file (if any) is 
requeued, the tracks for the input file (if any) are dropped, 
the faulty equipment is turned off, and error log messages are 
issued. The connect reject, function reject, transmission 
parity errors, and incomplete data transfer errors are retried 
ERRL (3) times while the 6681 and equipment function timeout 
conditions are not retried. 

If an error is encountered while reading the system sector, the 
file is released from BATCHIO with the following conditions. 

• The name of the file is changed to **BAD 

• The file type is changed to common (CMFT) 

• The write lockout bit is selected for the file; this will 
leave the file in the system for inspection by an analyst, 
but cause it to be ignored in further queue processing. 

The error messages issued by BATCHIO routines are listed in the 
NOS Reference Manual, Volume 1, appendix B. 

If BATCHIO is aborted or stopped, all active files are rerun by 
passing the rerun operator flag (RRNM) to 1CD through the buffer 
control word for each active equipment. This operation is 
performed by 110 overlay 3IC. 
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SYSTEM CONTROL POINT FACILITY 



18 



INTRODUCTION 

A system control point (SCP) provides a centralized facility for 
a module or group of modules to be used by one or more jobs 
residing at other control points, 
the following benefits. 



This centralization provides 



• A centralized control over items such as interlocks, 
resource allocation, and resource access. 

• Reduction in the overall usage of central memory. 
Instead of several jobs having this set of modules in 
their field length, only one set of these modules needs 
to occupy central memory. 

• The ability of the Network Access Method (NAM) to use 
the SCP facility to provide an interface between an 
application program and the network. This facility then 
provides the controlling element for communications to 
the network. 

The system control point facility provides a method of linking a 
user to a subsystem by means of connection indicators which 
reside with the control point that issues the call to the 
subsystem. This method is used to handle normal end, abort, and 
hostile users in such a way as to eliminate various undesirable 
situations which might otherwise occur in using the SCP facility 



CALLSS MACRO 



The CALLSS macro provides two-way communication between a 
subsystem residing at a particular control point and one or more 
user jobs residing at user control points CUCP), or from one 
subsystem to another. 



a UCP to request a particular 

UCP may call more than one 

in parallel. Also, a UCP may make 



The CALLSS macro is issued by 
function from a subsystem. A 
subsystem, either serially or 
more than one call to an individual subsystem. 

The CALLSS macro can be issued from a control point and generates 
the following RA+1 call (processed by CPUMTR). 



59 



RA + 1 



SSC 



41 39 35 



29 



w 



rsv 



17 



ss 



paddr 



r Autorecall bit (bit 40) 
rsv Reserved 
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ss Subsystem queue priority 

paddr The address within the calling control point's field 
length of the parameter list that defines the 
function to be performed; bit zero of the first word 
of the parameter list or block must be zero 



PARAMETER BLOCK 

The parameter block pointed to by parameter address paddr is 
used by the UCP to pass parameter information to the SCP. The 
parameter block must be at least one word in length. 

The first word of the parameter block is used for calling and 
status information. The second and subsequent words of the 
parameter block are used for data which is passed to the SCP by 
the operating system. The format of the first word is as 
f ol lows . 



paddr 



59 




35 




23 


17 


13 


11 







rss 


rin 


wc 


rcdc 


rt 


es 


c 



rss Reserved for subsystem 

rin Reserved for installation 

wc Word count; length of parameter List minus one that 
is passed with the request (maximum of 77B) 

rcdc Reserved for operating system 

rt Return control field set by the user prior to making 
the SSC or CALLSS call as follows: 



Bit 



12 



Desc ript ion 

Set to 1 indicates to the system that 
it is to return control to the user if 
the subsystem is present but unable to 
accept the user's call (for example, 
buffer full); bit 2 in the es field is 
set by the system in such an event 

If set to and the subsystem is 
present, the system will hold the 
request until the subsystem is able to 
accept it; the c bit is not set until 
the request is accepted and the 
processing of the request is finished 
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es 



13 set to 1 indicates that the system 
should: 

• Set the es field to indicate which 
error condition occurred 

• Return control to the user on 
nonfatal error conditions (fatal 
errors cause a UCP abort) 

If set to 0: 

• The es field is not set (except bit 
2 ) 

• All errors cause the UCP to abort 

Error and status bits; set to indicate error or 
unavailable system conditions; this field is not set 
if the rt field is zero: 



Bits 
1 

2 

3 

5-4 
11-6 



Value 


1 


1 


1 



Description 

Subsystem present 
Subsystem not present 

Subsystem not busy 
Subsystem busy 

Subsystem defined 

Subsystem not defined as SCP 

Reserved 

Error condition other than those 
already described in this field; 
may assume the following octal 
va lues : 



00 No error 
01-17 Reserved for system 

e mors 
20-67 Reserved for subsystem 

e mors 
70-77 Reserved for 

installations 



Completion bit; must be prior to function or 
call; set to 1 when request is completed 



macro 



MACRO FORMAT 

The CALLSS macro is available on systems text SSYTEXT and has 
the following format. 
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LOCATION 



OPERATION 



CALLS S 



VARIABLE SUBFIELDS 



ss,paddr ,r 



ss Subsystem queue priority 

paddr Parameter address as previously described 

r If r is specified, control is not returned to the 
caller until the operation is complete 



SFCALL MACRO 

The SFCALL macro is issued only from a subsystem. It generates 
the following RA+1 call (processed by CPUMTR) . 



59 



RA+1 



40 35 



17 



SSF 



I 



rsv 



saddr 



r Autoreca libit 
rsv Reserved 

saddr The address (ap+O) within the subsystem of a two- or 
three-word parameter block that defines the function 
to be performed 



MACRO FORMAT 

The SFCALL macro is available on systems text SSYTEXT and has 
the following format. 



LOCATION 



OPERATION 



SFCALL 



VARIABLE SUBFIELDS 



saddr , r 



saddr Parameter address as previously described 
r Autorecall 



60454300 B 



18-4 



PARAMETER BLOCK 

The oarameter block for the SFCALL * consi st s of two or three 
words! depending upon the function code. The first two words are 
defined as follows. 



ap+O 



+ 1 



59 


53 




41 


re 


fp 


ucpa 




job sequence number 




re Reply code 



34-37 

40 

41 

42 

43 

44 
45 

46-55 
56 

5 7 
60 
61 
62 
63 
64 
65 
66 
74-77 



No error encou 
Reserved for i 
At least one e 
Job ident i f ier 
SCP address no 
length 

UCP address no 
length 

User job is sw 
User j ob is no 
Reserved for s 
Un recove rable 
occurred durin 
Connection, pre 
Connection rej 
Connection not 
Word transfer 
UCP not establ 
Subsystem esta 
Attempt to set 
Illegal dayfil 
Reserved for i 



ntered 

nstal lations 
rror detected 

i s i nva lid 
t within SCP CM 



in list 

or ECS field 



t within UCP CM or ECS field 

apped out 
tin system 
ystem 

ECS abort or parity error 
g ECS data transfer 
viously established 
ected 
previously established 

too long 

ished with subsystem 

blished with receiver 

illegal error flag 
e processing flag 
nsta I lat i ons 



fp Function parameter for particular function code 

ucpa Relative CM address within UCP 

scpa Relative CM address within the subsystem 

fc Function code 

The extended read and extended write SFCALL functions (refer to 
Junction codes SF.XRED and SF.XWRT) have three-word parameter 
blocks, with the third word defined as follows. 
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59 



47 



23 



ap+2 



us reserved 



eucpa 



escpa 



u If bit 59 is set, eucpa is the UCP ECS address; 
otherwise eucpa is the UCP CM address 

s If bit 58 is set, escpa is the SCP ECS address; 
otherwise escpa is the SCP CM address 

eucpa Extended read or write UCP CM or ECS address 

escpa Extended read or write SCP CM or ECS address 

SFCALL FUNCTION CODES 

The following is a list of function codes (fc) possible on 
SFCALL macro calls. The fc is always an even number that is 
incremented by one when the function has been completed. 



Symbo I 


Va lue 


SF.REGR 


02 


SF.ENDT 


06 


SF.READ 


10 


SF.STAT 


12 . 


SF.WRIT 


14 


SF.EXIT 


16 


SF.SWPO 


24 


SF.SWPI 


26 


SF.SLTC 


30 


SF.CLTC 


32 


SL.LIST 


34 


SF.XRED 


40 


SF.XLST 


42 


SF.XWRT 


44 



Description 

Place message into UCP's dayfile 
and/or abort UCP 

Indicate end of task to UCP 

Read UCP CM FL 

Request the status of a UCP 

Write to UCP CM FL 

Exit from subsystem status 

Indicate UCP is swapout candidate 

Request system to swap in UCP 

Set long-term connection 

Clear long-term connection 

Multiple request capability to 
process a list of SF.xxxx functions 

Extended read of UCP CM or ECS 
field length 

Extended list processing 

Extended write of UCP CM or ECS 
field length 
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Symbo I 

SF.INS1 

SF.INS2 

SF.INS3 

SF.INS4 



Va Lue 
70 
72 
74 
76 



Desc ri 



Reserved for i 
Reserved for 
Reserved for 



pt ion 



nsta I lat ions 
nsta I Lat i ons 
nsta Llations 



Reserved for installations 



CALLSS PROCESSING 

The UCP uses the CALLSS macro to communicate with a particular 
subsystem via the SCP facility. The UCP must have permission 
for communication with a subsystem via the SCP. The permission 
required is the setting of the CUCP bit (bit 12) of the access 
word (AW). If the validation is improper, the UCP is aborted 
immediately by the system* without allowing EREXIT, REPRIEVE, or 
EXIT processing. 

The amount of data transferred to the SCP (placed at the address 
defined by ap in the subsystem's RA.SSC word) depends upon 
whether the subsystem has requested a fixed amount of data (v 
bit in RA.SSC cleared) or a variable amount of data (v bit set). 
If data is fixed length, the total amount of data moved to the 
subsystem is lp words (taken from the RA.SSC word). This amount 
includes the two-word header at ap+0 and ap+1 . 

For variable length data, the system transfers wc+1 (taken from 
the CALLSS parameter block) words in addition to the two-word 
header. The subsystem determines how much data was actually 
moved by extracting the wc value from the data word at ap+2. 
This word corresponds to the first word of the UCP parameter 
block on the CALLSS. 

Following the processing of the CALLSS macro (checking parameter 
validity and moving the UCP parameter block to the subsystem FL) , 
the operating system causes the subsystem to be assigned a CPU 
if it is of higher priority than what is currently running. The 
subsystem then executes as a normal job. The subsystem receives 
the remainder of the UCP's CPU slice if the CALLSS was issued 
with or without autorecall. This is done to ensure that the 
system is not saturated with CALLSS requests that cannot be 
sat isf i ed. 



SUBSYSTEM/UCP COMMUNICATIONS PATH 

There must be information available to allow the operating 
system to properly manage intercontrol point communications. 
This is provided by connection indicators residing at the 
control point that issues the CALLSS to a subsystem. 

Four bits are assigned to each possible subsystem. One of these 
bits indicates that the UCP has been granted access to the 



* SYET error flag is set on unauthorized UCP. 
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subsystem and the others indicate the number of requests 
awaiting a response from the subsystem. 

The bit indicating that access has been granted is set on request 
of the receiving subsystem through the SFCALL macro. The 
function which sets this bit is SF.SLTC (set Long-term 
connection). This bit remains set until cleared either by 
n. OVERRIDE or on request of the appropriate subsystem. 

The field indicating that the UCP is awaiting response from the 
subsystem is incremented by the operating system whenever a 
CALLSS is issued. 

The long-term connection can be set only when the wait response 
field is nonzero. This is necessary to protect the UCP from an 
unsolicited connection being established arbitrarily by a 
subsystem. 

This 3-bit wait response field causes the UCP to be locked-in 
(not a normal candidate for rollout). This field is zero when 
no outstanding requests remain for the appropriate subsystem. 

Whenever the wait response field is nonzero, the operating 
system inhibits rollout of the UCP. This is accomplished by 
giving the UCP an installation specified number times its normal 
CM slice whenever the UCP has outstanding wait response 
indicators set without corresponding swapout allowable 
indicators set. Then after the CM slice has expired, the UCP is 
considered a normal candidate for rollout. 

Before the wait response field is incremented, a check is made 
to see if the maximum is met (seven outstanding requests). When 
the maximum is attained, the next request forces the UCP into 
recall, if recall was selected on the call, until at least one 
outstanding request has been satisfied through a subsystem 
response that decrements the count in the wait response field. 

(The SF.ENDT function issued by the subsystem causes the wait 
response field to be decremented.) 

If recall is not selected on the call, RA+1 is cleared and the 
subsystem busy status is returned to the user. The maximum 
number of outstanding requests in the wait response field is an 
installation parameter initially set to 7 (maximum field size). 



CONNECTION STATE TABLE 

Although one subsystem is shown in table 18-1, the same 
conditions exist independently for all possible subsystems 
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TABLE 18-1. CONNECTION STATE TABLE 



{User Control Point State I A I B | C I D 

i— —i — j j- — j— - 

jLong-Term Connection | N | N | Y | Y 

|Wait Response Nonzero | N | Y | N | Y 

j No Connection | X | I I 

JAwaiting Response I I X | , 

| Locked In* I I X X 

ICandidate for Rollout I X I I X | 

|SF.SLTC Allowed I | X j I 

|SF.SWP0 Allowed I | X | I X 

| SF.SWPI Allowed I I I X I 

ISF.CLTC Allowed I I | X | X 



The following steps refer to table 18-1. 



5. 



6. 



Initially, any control point is in state A. 

When a control point in state A issues a CALLSS macro 
(except for the special initialization call to the 
operating system; refer to SSF Call Processing), it is 
placed in state B by the operating system if the 
subsystem exists. This locks the UCP until the 
subsystem replies. 

The subsystem then must reply to the request which 
places the requestor in state A or C. 

In any state except state A, the subsystem may respond 
with the hostile user SFCALL that eliminates the caller 
Refer to Hostile User. 

Refer to End Processing for proper action by a UCP or a 
subsystem on normal termination. 

Refer to Abort Processing for information about what 
happens when either a UCP or a subsystem aborts. 



END PROCESSING 



It is necessary to inform the subsystem(s) when a control point 
established in communication ends. The procedure described here 
is for normal end cases. 



• Locked in implies the UCP is given an installation specified 
number of times is CM slice before rol lout, occurs . 
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End UCP 

It is possible for any UCP to inform its subsystemC s) that it 
is ending. That is, every subsystem should have a provision to 
have its connection disestablished on request. 

In the event it does not, the operating system uses the 
following procedure. 

If the UCP ends in any state other than A (refer to table 18-1), 
the operating system initiates termination processing identical 
to abort processing except that the status is end rather than 
abort. The user job remains in the system, in either case, 
until the subsystemC s) c lears all of the outstanding connection 
indicators or operator intervention occurs (n. OVERRIDE . ). 

End Subsystem 

A subsystem is in a different position than a UCP since requests 
come to it unpredictably. In order to establish a logical 
termination procedure, the subsystem must first disallow the 
receipt of further requests (clear RA.SSID). It should next 
answer all outstanding requests (UCPs in state B, C, or D) with 
a message indicating the subsystem is terminating, and then it 
should end . 

When 1AJ detects that a subsystem has ended, reprieve processing 
is checked and allowed for the subsystem. The subsystem should 
have an established cleanup procedure to inform UCPs of the 
end. After the reprieve processing (or if no reprieve 
processing was established), 1AJ checks the outstanding 
connection count (word SSOW) in the subsystem's control point 
area. If the count is nonzero, 1AJ attempts to set the subsystem 
end/abort interlock bit (INWL word, bit 0) via the UADM monitor 
function. If unable to do so, 1AJ is placed in recall. It then 
performs an FNT search and depending upon the file type performs 
the following steps. 

1. If at a control point, 1AJ issues an SFIM monitor 
function* to attempt to interlock that particular FNT 
entry. If unsuccessful, 1AJ pauses and reissues the 
SFIM. When the FNT interlock is set, a CEFM monitor 
function sets the SSET (subsystem aborted) error flag 
on the specified UCP. The FNT interlock is then 
cleared via another SFIM call and the FNT search 
continues. Upon setting the FNT interlock, the job must 
be reexamined to determine whether the job state has 
changed. If the state has changed, the UCP is handled 
according to its current state. 

2. If the job is in the rollout queue (ROFT) or timed event 
rollout queue (TEFT), the FNT interlock is used (SFIM) 



* The SFIM monitor function controls the transition states (state 
of rolling in or out) of jobs in the system. 
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and if successful bit 5 of the FNT is examined- If set, 
the system sector is read to determine whether the UCP 
had connections with the aborting subsystem. If bit 5 of 
the FNT is not set or if no connections were 
established, the FNT interlock is cleared. If 
connections are established, the FNT pseudo channel 
CFNCT) is used as an interlock to allow 1AJ to change 
the error priority to SSPS. File types TEFT are changed 
to ROFT. The FNCT channel and S FIM i nter loc ks are then 
released and the search continued. 

A UCP in state A (that is, without long-term or wait 
response status) at the time of subsystem end is not 
informed of the ending condition. Subsystems must 
place all UCPs which require notification in the long- 
term state. 

After going through the preceding procedure, all jobs which were 
in state B, C, or D with the subsystem are informed of the end 
condition. Other UCPs (those which were in state A at the time 
of the subsystem end) receive a subsystem not present status 
from the operating system if they attempt a CALLSS after the 
subsystem is actually dropped. If these jobs attempt a CALLSS 
during the end process, they also receive the subsystem not 
present status. 

Subsystems which deal with UCPs on a short-term basis only (that 
is, no long-term connection) must be designed to allow for 
proper resynchroni zat ion with the UCP if the subsystem ends. 



ABORT PROCESSING 

It is necessary to inform the subsystem when a control point 
established in communication aborts. 

Whenever a UCP tries to terminate in any state other than A, the 
subsystem is informed via a message generated by the operating 
system and sent to the subsystem. It is the responsibility of 
the individual subsystems to clear any outstanding connections 
with the UCP. This may be done by individual SF.CLTC and SF.ENDT 
requests or by a special SF.ENDT request (UCPA = -1) which clears 
all outstanding connections for this subsystem. The UCP remains 
in the system until all subsystem connections are cleared. 

This method of informing the subsystem of the UCP abort is 
handled by 1AJ through the monitor function TDAM. All wait 
response and long-term connection bits are checked. If any are 
set, the appropriate subsystem queue priority is obtained from 
the connection indicators position (subsystem index). This 
queue priority is then used by the TDAM function to inform the 
appropriate subsystem. The connection indicators remain set 
until cleared by the SCP or an n. OVERRIDE command is issued. 
Thus the UCP remains in the system and no job advance occurs 
until these connection indicators are cleared. 

The format of SSCW is as follows. 
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sscw 



59 




47 


43 


39 


35 


31 


27 


23 


19 


15 


11 


7 


3 


swap 


SS11 


ss10 


ss9 


ss8 


ss7 


ss6 


ss5 


ss4 


ss3 


ss2 


ss1 


ssO 



swap 



ss ( i ) 



Swapout allowable indicator for 
subsystem indexes 11 through 0. 

4-bit subsystem indicator. The upper 
bit indicates long-term connection, if 
set, for subsystem index i, The lower 3 
bits are the wait response indicator 
count (number of outstanding requests to 
a maximum of 7) for subsystem index i. 



In the TDAM monitor function, the job sequence number, FST 
address, and error flag are then sent to all the appropriate 
subsystems- If the call is not accepted, a check is made to see 
if the subsystem is inactive (a reply code of 4 from TDAM). If 
the subsystem is active but the call was not accepted, the 
message is reissued. If the subsystem is inactive* or the call 
was accepted, the message is issued to the next appropriate 
subsystem.** 

NOTE 

1 AJ issues a special TDAM request 
which CPUMTR traps to send to the 
receiving buffer pointed to by 
RA.SSC. 

The format of RA.SSC (RA+51) is as follows. 



59 53 



xp 



35 



17 



ap 



Set by CPUMTR when a request has been 
placed in the parameter area. It is 
cleared by the subsystem to acknowledge 
the request has been received. When the 
bit has been cleared, ap should point to 
a parameter area which the subsystem is 
prepared to receive on the next request. 
After clearing this b i t > the subsystem 
should not attempt to rewrite RA.SSC 
until the next request is received. 



* If the subsystem is inactive the connection indicators for 

this subsystem are cleared at this time. 
** 1AJ is placed in PP recall if any subsystems are busy. 
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xp 



Ip 
ap 



If bit 58 is zero, the system does not 
impose any additional restrictions on 
access by UCPs for this subsystem (no 
additional validation is required 
besides CUCP bit set in access word). 
If set, the system allows access to the 
SCP (CALLSS macro request transfer) only 
by UCPs that are privileged programs. A 
privileged program is one with an SSJ= 
entry point or a queue priority greater 
than MXPS (subsystem). These 
restrictions also imply that the UCP 
program was loaded from the system 
library. Unauthorized UCPs are aborted 
immediately by the system* without 
allowing EREXIT, REPRIEVE, or EXIT 
processing, and no data is transferred 
to the SCP's CALLSS receiving buffer. 

Address within the subsystem for the UCP 
exchange package. 

If set, indicates that wc words (refer 
to CALLSS Macro) are transferred from 
UCP rather than Ip. This allows the UCP 
to transfer a variable number of words 
(< Ip) to the subsystem. 

Length of the request parameter area. 

Address within the subsystem for UCP 
pa ramet ers . 



The format of location ap is as follows. 

59 47 23 17 

ap 



reserved 
for install 



reserved for system 



status 



addr 



JL 



status 



This field may assume the octal values 
through 77: 

00 Normal UCP messages (addr not 
equal to 0) 

01 System message (UCP ended) 

02 System message (UCP aborted) 

03 Connections forcibly broken 
(n. OVERRIDE.) 



* SYET error flag is set on unauthorized UCP. 
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04 SCP aborted (this status is 

returned to a UCP that is also an 

SCP) 



addr 



Address of a parameter block for this 
request (same as parameter address on 
SSC call; refer to CALLSS macro). If 
this field is set to 0, the system has 
generated this message with status bits 
set indicating end or abort conditions 
of the UCP. 



Processing for end is th,e same except that the end status is set 
rather than abort. When the subsystem aborts, this procedure 
should be essentially identical with end processing. 



HOSTILE USER 

The hostile user flag is used by subsystems to protect 
themselves from UCPs that are possibly endangering the system. 
The subsystem, through this flag, blocks normal exit processing 
so that the offending UCP is forced from the system.* 

This is a powerful feature that requires some limitations in 
order to protect users from themselves. Sufficient protection 
should be provided to ensure the following. 



• The request to set 
subsystem . 



the hostile user flag is issued by a 



• The control point receiving the hostile user flag is in 
state B, C, or D with the issuing subsystem. This 
assures that the flag is being set judiciously by a 
solicited subsystem. 

• The subsystem issuing the request is not in state B, C, 
or D with the receiver. Two subsystems may be connected 
to one another with the hostile subsystem attempting to 
set the hostile user flag on the nonhostile subsystem. 

These checks minimize the UCP's ability to jeopardize the 
performance of the SCP facility. 



COMMUNICATION ENDS AND ABORTS 

If the UCP is in a state other than A, an error flag SSET is set 
on the UCP. 



*The SYET error flag is used to identify the hostile user, 
is handled in 1AJ so as not to allow exit or reprieve 
processing. 



SYET 
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The operating system places information in bits 23 through 18 of 
the ap word (refer to Abort Processing) which indicates end or 
abort conditions of the UCP. 

In order to communicate with subsystems of all types, system 
messages are two words in length. These messages consist of 
word ap + and ap + 1 only. This is necessary in order to 
observe the stated rule that the minimum value of lp is two. 

Also, these two words are sufficient to identify the UCP of 
interest. The system generates the message with addr equal to 
zero and a normal word at ap + 1. 



CPUMTR PROCESSING OF SSC CALLS 
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RA.SSID 



sspn 



ss code 



sspn 
ss code 



Subsystem program name 
Subsystem queue priority 



RA.SSC (refer to Abort Processing) is a pointer that tells CPUMTR 
where to put incoming requests from a UCP. The parameter area 
can receive a request when bit 59 is zero. 

CPUMTR sets bit 59 when the transfer is complete. It is cleared 

by the subsystem whenever the buffer pointed to by apis ready 

for more data. The subsystem should never update RA.SSC unless 
bit 59 is set. 

Because subsytems in general using the SCP facility have a high 
CPU priority, the subsytem should acknowledge receipt of the 
request as soon as it is able to do so. 

Whenever an SSC call is made with recall, CPUMTR sets RA+1 of 
the UCP to the following. 
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RA+1 



RCL 



FT 

/ 

/T 

/ 



w 



qp 



addr 



r 

qp 

addr 



Autoreca Libit 

Queue priority of subsystem CALLSS 

i ssued to 

Address of the parameter block 



CPUMTR checks the UCP control point area (refer to Abort 
Processing) to ensure that the UCP has seven or fewer 
(installation defined) requests outstanding. If not, the UCP is 
placed in recall. If recall was not selected on the call, RA+1 
is cleared and the subsystem busy status is returned. If the 
subsystem code is nonzero, CPUMTR checks its validity and finds 
the subsystem control point address. Table 18-2 summarizes the 
other checks made at this time (refer to CALLSS Macro, parameter 
block description). 



TABLE 18-2. UCP/ SUBS YS TEM CHECKS 



Subsystem State 



Return (rt) 
Code Field 



Act ion 



Subsystem not 
present, or 
ap + Ip >FL 



Subsystem busy * 
(bit 59 of 
RA.SCC is set) 



xp not 



xp = 



Bit 13=0 



Bit 13=1 



Bit 12=0 
Bit 12=1 



NA 



NA 



Abort UCP and set error 
f lag . 

Clear RA+1 and set es 
bit 1 . 

P lace UCP i n recal I . 
Clear RA+1 and set es 
bit 2. 

Move UCP exchange 
package to xp. 

Do not move exchange 
package . 



After completing the validity checks, CPUMTR moves the job 
sequence number and FST address to ap+1 . Then the parameter 
block is moved from the UCP to the subsystem by either a variable 
length move of data if v (bit 35) of RA.SSC is set or else a 
fixed length move of data if v is cleared (refer to SFCALL macro) 
At this point, CPUMTR increments the wait response indicator to 



* Subsystem is being storage moved, advanced, or user control 
point has reached the maximum allowable number of outstanding 
requests. 
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inhibit subsequent rollouts. The wait response indicators being 
nonzero allow the UCP to get an installation specified number 
times its CM slice. (Refer to SF.SWPO for overriding the wait 
response indicators.) 
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TABLE 18-3. CHECK USER JOB TABLE 



UCP State 

Job identifier is invalid 




UCP address is out of range 
(ucpa or eucpa + fc if 
app li cab le) 

UCP is swapped. 

Job identifier on SSF call 
does not match that of UCP|s 
control point area. User job 
not in system. 



SF.ENDT (06) 



This function informs the operating system and the UCP that the 
subsystem task has been completed. 



If none 
made on 
zero. If 



of the errors in table 18-3 were encountered, a check 

the wait response indicator field to see if the field 

it is, error status 63B (UCP not established with 



subsystem), is returned. If the field is nonzero, it is 
decremented from the subsystem control word (SSCW). 

If the count then equals zero, the UCP is scheduled normally, 
according to the queue priority present in the control point 



1 s 
i s 
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area. If the ucpa field is equal to a minus one, all 
outstanding connections are cleared from the UCP control point 
area for this subsystem. If the UCPA field is nonzero and 
positive, this field is used as the address of the CALLSS 
complete bit (bit Q) and the bit is set (corresponds to address 
addr supplied with CALLSS). If bit 42 of the fp field is set, 
the CPU is switched immediately from the SCP to the UCP if the 
UCP was in recall on this CALLSS. 



SF.READ (10), SF.WRIT (14) 

SF.READ and SF.WRIT transfer data (up to 100B words) from the 
UCP's CM field length to the SCP's CM field length or vice versa. 

All transfers of data are done by the compare/move unit (CMU), if 
available and not a dual CPU configuration, or by the generalized 
8-word move loop. 

CPUMTR first checks for the fatal error scpa+fp out of range and 
issues the error status 42B (SCP address is not within the 
subsystem CM FL) if necessary. The user job is then checked as 
in table 18-3. If the wait response field is zero, error status 
63B (UCP not established with subsystem) is returned. If fp 
exceeds the maximum transfer size (currently 100B), error status 
62B (word transfer too long) is returned. 

If no errors occur, fp words are then either moved from ucpa to 

scpa (SF.READ), or moved from scpa to ucpa (SF.WRIT). 

Completion bits are then set in the SSF call and RA+1 is cleared. 



SF.XRED (40), SF.XWRT (44) 

These functions allow the transfer of data (length 
by 12-bit fp field size*) from the UCP's CM or ECS 
to the SCP's CM field length and from the UCP's CM 
ECS field length (SF.XRED) or from the SCP's CM to 
field length (SF.XWRT).** 



I imi ted on ly 
field length 

to the SCP's 
the UCP's ECS 



The u and s fields in the third word Of the parameter block 
(ap+2) indicate whether the eucpa and escpa fields are CM or ECS 
addresses in the UCP and SCP. The ucpa and scpa fields in word 
one of the parameter block (ap+0) are not used for these 
f unct ions . 

CPUMTR first checks for the fatal error escpa+fp out of range 
and issues the error status 42B (SCP address is not within the 
subsystem CM/ECS field length) if necessary. The user job is 
then checked as in table 18-3. Reply code 43B is returned if 



* Although large transfer lengths are allowed, the system 

overhead to move large amounts of CM or ECS in monitor mode is 
extensive and overuse is a misuse of the SCP facility. 
** Direct transfers from UCP ECS to/from SCP ECS is not 

supported; SCP is aborted with monitor call error if such a 
transfer is requested. 
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eucpa+fp is not within the UCP's appropriate CM or ECS field 
Length. If the wait response field is zero, error status 63B 
(UCP not established with subsystem) is returned. 

If no errors occur, as much of the transfer is processed as 
monitor mode time for one RA+1 request allows.* To prevent 
performance degradation, CPUMTR prematurely terminates CM and 
ECS transfers requested by SF.XRED and SF.XWRT functions when 
time allowable in monitor mode is exhausted, and then decrements 
wc to the remaining word count, increments escpa and eucpa 
addresses by the transferred data length, sets the complete bit, 
and returns control to the SCP. To complete the read/write, the 
SCP must reissue the SF .XRED/SF .XWRT SSF RA+1 call until wc is 
zero. 

An SCP requesting a data transfer of less than or equal to 100B 
words via SF.XRED or SF.XWRT does not have to check the word 
count to guarantee the data transfer is complete, since 
transfers of less than or equal to 100B words are not fragmented 
(compatible with SF.READ and SF.WRIT functions). 

To allow use of SF.XRED and SF.XWRT in a list, the extended list 
function SF.XLST, with two words per list entry, must be used. 
The second word of the SF.XLST list entry for an SF.XRED or 
SF.XWRT function corresponds to the third word of the nonlist 
SF. XRED/SF. XWRT parameter block. Large data transfers requested 
by SF.XRED or SF.XWRT within an SF.XLST are prematurely 
terminated when monitor mode time is exhausted; the amount ot 
data transferred depends on the number and complexity of prior 
functions in the list that have already been processed during 
this RA+1 request. The S F. XRED/SF .XWRT wc field is decremented 
to the remaining word count and the escpa and eucpa addresses 
are incremented by the transferred data length. The complete bit 
is not set on the SF .XRED/SF .XWRT function in the list, and the 
list address Cscpa field in first word of SF.XLST parameter 
block) remains pointing to the SF . XRED/S F .XWRT f uncti on unti I a 1 1 
data has been transferred (wc=0), so that subsequent reissue of 
the SF.XLST SFCALL by the SCP continues the data transfer where 
it left off. 

The inclusion of an SF.XRED or SF.XWRT function in an SF.LIST 
list (one word per entry) causes the SCP to abort with a monitor 
call error. 

SF.EXIT (16) 

With this function the subsystem is removed from SCP status.** 



** 



The amount of data that can be transferred at one time 
depends upon the CM and ECS transfer rates estimated f 
machine. The CM transfer rate is varied depending upo 
whether the machine has a CMU or is a stack machine, 
transfer rate is varied depending upon the ECS size, a 
whether ECS is shared in a mu It imainf rame environment. 
RA.SSID is cleared (the subsystem remains a subsystem 
longer acts as a SCP). 
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When CPUMTR processes this request, it determines the UCP's 
associated with this subsystem to inform them that the subsystem 
is ending its SCP status (refer to End Processing for a further 
discussion of this case). 

SF.SLTC (30), SF.CLTC (32) 

These functions are used to control the state of the Long-term 
connection bit belonging to the UCP. The operating system 
defines a bit position belonging to each subsystem so that it is 
only necessary to ask for the bit to be set or cleared at the 
proper time. (CALLSS processing discusses the various states 
possible when using these functions in relation to the wait 
response field previously discussed.) 

SF.SLTC - Set Long-Term Connection 

Possible status returns are the following. 

00 Connection established 

57 Connection previously established 

Existing status returns 41, 44, 45, and 63 may also occur. Any 
error will cause the long-term connection to remain in its 
original state. 

SF.CLTC - Clear Long-Term Connection 

Possible Status Returns are the following. 

00 Long-term connection disestablished 
61 Connection not previously established 

As in SF.SLTC, status returns 41, 44, and 45, may occur. Any 
error will cause the long-term connection to remain in its 
o ri gi na I st ate . 

SF.STAT (12) 

The subsystem requests the current status of the user job. The 
re field is used for reply. 

re Desc ri pt ion 

The user's job is in a normal state of execution 

41 Job identifier invalid 

44 The user job is swapped or swapping 

45 Theuserjobisnotinsystem 

The status of the connection indicator is returned in fp when re 
is in the following format. 
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53 



45 40 



pu 


1 


re 



re 



If zero, UCP is not a privileged program. If set, 

UCP is a privileged program. A privileged program 

is one with an SSJ= entry point or a queue priority 
greater than MXPS (subsystem). 

If zero, UCP is not a privileged user. If set, 
UCP is a privileged user. A privileged user is a 
system origin job or a user with system origin 
privileges (CSOJ bit set in access word) when the 
system is in DEBUG mode. 

Long-term connection 

Request count 



The ucpa and scpa fields are not used on this call, but should 
be zero in case of future expansion. 



SF.SWPO (24) 

This function indicates that the UCP is a candidate for rollout. 
CPUMTR checks the user job for error status returns 41, 44, 45, 
and 63. If there are no errors the swapout allowable field is. 
set in the subsystem control word SSCW and the UCP is checked for 
the conditions necessary to swap out the UCP as described under 
CPUMTR Processing of SSC Calls. For each set of wait response 
indicators set, there must be a corresponding swapout allowable 
indicator set. If these conditions are met, CPUMTR calls 1MA to 
the UCP control point to set the forced rollout priority (FRPS) 
on the UCP and to set the SF.SWPO completion bit. If these 
conditions are not met, the completion bit is set and the 
function is completed. 

Because the wait response field remains unchanged after this 
function, 1SP checks the swapout allowable field before checking 
the wait response field. If the swapout allowable field is set, 
1SP does not check the wait response field for this subsystem. 

field set to 




slice and normal scheduling occur (refer to SSCW word). 



NOTE 



The following special subsystem requests are 
accomplished by use of the monitor auxiliary 
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processor (1MA) because of the overhead involved 

in doing the request in monitor mode. Routine 

1 MA must be CM resident in order for data to be 

passed by CPUMTR to 1MA through the message 

buf f e r . 



SF.REGR (02) 



This function sends a dayfiLe message and/or aborts the UCP. 
Several checks are made by CPUMTR prior to calling 1MA for 

assistance. CPUMTR and 1MA checks determine the current state 

of the UCP with the subsystem (refer to CPUMTR Processing of SSF 
Call) and issue the following error codes if appropriate. 

63 UCP not established with this subsystem. (Not in state 
B, C, or D) 

64 Issuing subsystem is established with the receiver 
(UCP i s a subsystem) 

65 Attempt to set an illegal error flag 

66 Illegal dayfile processing flag * 

(The subsystem wants to abort the UCP, but has issued 
an improper error flag.) ** 

Error status returns 41, 42, 44, and 45, are also possible. 

If no errors occur, a value of zero in the ucpa field means the 
error flag at the UCP remains unchanged. Otherwise, the error 
flag is set to ucpa. If there are other subsystems involved with 
this UCP, NOS performs abort processing (refer to Abort 
Processing). Finally, if scpa is nonzero, 1MA issues the message 
beginning at scpa to the UCP dayfile. Currently the maximum 
message length is 4 words (40 characters). This maximum is 
imposed because CPUMTR prestores the message in the 1MA message 
buffer and then calls 1MA to the UCP control point. Routine 1MA 
upon completing this function sets the complete bit by means of 
the TDAM monitor function due to the fact that IMA is assigned to 
the UCP. 



SF.LIST (34), SF.XLST (42) 

Multiple special subsystem requests to be made with a single 
SFCALL request. The format of the S F . LIST/S F . XLST function 
parameter word pair must be as shown for the SFCALL macro. 



* fp is an invalid dayfile index. Valid range of indices is 
f rom to 7 . 

** Presently the only legal error flags are: 

SF.SEXX (1) - set normal subsystem ' C FSET) error flag 
SF.SEHX (2) - set hostile user (SYET) error flag 
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The scpa field in the S F .LIST/SF .XLST parameter block points to 
a List of SFCALL functions to be processed for one UCP 
(identified by job id in second word of S F. LIST/SF -XLST 
parameter block). The wc field contains the number of SFCALLs 
in the list. 
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Before processing any functions in the List, the S F.L JST/SF.XLST 
function itself is validated and the user 30b cheeks defined by 
table 18-3 are performed. If all these checks P"»»J ?^ 
error, processing of individual entries within the list is 
inU ateS! If the UCP is swapped out, an SF LIST is rejected 
with RC44 even though an SF.SWPI may be the first function 
requested within the list. 

When the SF. LIST/SF. XLST parameter word pair's fc "•"*«»?* 
complete by the operating system, the re and fp fields must be 
examined for proper action. The order of examine these fields 
must be determined by the subsystem design. 

The SF. LIST/SF. XLST call is processed partially by CPUMTR and 
1MA. The functions which CPUMTR processes are d ° ne T 1 " ra °" 1 * 0r the 
mode; as such, these functions are time en ti cal . Theref ore, the 
number of functions processed by CPUMTR may not exhaust the list 
in order to avoid serious system degradation. 

Also, various other functions are considered time '°"^ min 9 in 
themselves. These functions are proce ssed by IMA ™ u Jj J* £ 
quite likely when processing a large list of functions that tne 
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entire list will not be exhausted in one pass. The following 
paragraphs discuss what happens when this occurs. 

• If fp is 0, the enti-re list has been processed by the 
operating system. If fp is nonzero, it indicates that 
processing of the list was abandoned by the operating 
system. The value of fp is set to the number of entries 
remaining is the list and scpa is set to the address of 
the first entry in the remaining list. Essentially, the 
subsystem may reissue the S F . L 1ST / S F . XLST call by 
resetting the fc field and executing the SFCALL macro 
until fpisO. 

• It is also important to check the re field to determine 
if any errors occurred while processing the list. The 
operating system sets the field only if an error is 
detected, so it is the responsibility of the subsystem 
to initialize this field, prior to the SFCALL. Since the 
operating system does not check the re field, but only 
sets it on errors, multiple issues of the same 
SF.LIST/SF. XLST. request (until fc is set complete ancl fp 
is zero) accumulate error returns whether or not the 
entire list is processed on one SFCALL. 

• The operating system only aborts the SCP during. 
SF.LIST/SF. XLST processing if the scpa is not within the 
subsystem's FL (42B error) or if any fatal errors are 
encountered during list processing. Error 42 implies 
that none of the list has been processed. This check is 
made prior to initiating the list process on the first 
and only word pair. This address must point to the list 
of contiguous function words Cone word per function) to 
be performed for this particular user. Subsequent fatal 
errors are returned in the function's reply code with a 
40B error set in the first word pair. 

• The detailed error conditions must be determined by 
examining the individual list entries whenever the 
SF.LIST/SF. XLST fc field equals 40B. 

• List entries are processed sequentially by the operating 
system and those entries detected as erroneous for any 
reason are considered completed. It is expected that in 
most cases the entire list will be processed on one 
SFCALL. The option of abandoning the list is provided 
to allow the operating system to take corrective action 
if it decides that either the length of the list, the 
complexity of the processing, or other reasons have 
caused an excessively long un i nter rupt ab le interval. 

• If the SCP is aborted due to an error in one of the list 
entries other than the S F . LIST/S F . XLST, re = 40B, scpa 
and fp are updated, and fc is set complete. The proper 
return statuses are also placed in the offending list 
entry. 
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SF.SWPI (26B) 

The user job is checked to see if it is at a control point. If 
it is at a control point*, CPUMTR sets the completion bit and 
clears the swapout allowable indicator in the subsystem control 
word. If the user job cannot be found, a user job not in the 
system error (45B) is returned and the completion bit is set. If 
the user job is in the rollout queue, CPUMTR calls 1MA and 
processes this function. If the UCP has been swapped out, 1MA 
checks the control point assignment in the UCP's FNT. If equal 
to 37B, the user job swapped out status is returned. 

This condition only occurs when two subsystems issue this 
function on the same UCP when the UCP is in the rollout queue. 
The error occurs because the other subsystem has already begun 
the swapin procedure, and the queue priority must identify the 
subsystem. 

Routine 1MA sets the FNT interlock (SFIM) and checks the special 
subsystem range of queue priorities beneath MNPS. If the queue 
priority is not in the range, it is set for the subsystem which 
issued the SF.SWPI, the control point assignment is set to 37B, 
and the FNT interlock is released. Then the subsystem queue 
priority and the address of the SF.SWPI completion bit is stored 
in the rollout file system sector at location SWSS and the 
control point assignment removed. The control point assignment 
is used as an interlock on the system sector write. Later, 1SJ 
checks for this subsystem related queue priority range beneath 
MNPS and forces the maximum queue priority for this origin type 
to assure rollin of the UCP. 



Then wh 
checks 
queue p 
t he ref o 
p ri ori t 
address 
the ro I 
subsy s t 
for out 
i ssued 
was not 
call, 
the swa 
is the 
bit bef 



en 1 
the 
r i or 
re t 

y). 

of 
lout 
em i 

of 
and 

out 
This 
pout 
resp 
ore 



RI i 
same 
i ty 
he F 

Rou 
the 

fi I 
s f o 
rang 
the 

of 

bit 

all 
ons i 
atte 



s ca 
sub 
ass i 
ST s 
tine 
comp 
e sy 
und* 
e . 

subs 
rang 

i s 
owab 
bi li 
mpt i 



lied, assuming the UCP was selected, 1RI 
system related queue priority range (this new 
gned by 1SJ is only done internally; 
till contains this special subsystem related 

1RI obtains the subsystem queue priority and 
letion bit address for the SF.SWPI call from 
stem sector. The control point of the 
* and the completion bit address is checked 
If out of range, a system dayf i le message is 
ystem is aborted. Finally, if the address 
e the completion bit is set for the SF.SWPI 
only set when the UCP has been swapped and 
le field is cleared for this subsystem. It 
ty of the subsystem to check this completion 
ng to communicate with the UCP. 



* The flag for SF.SWPO in progress (bit 12 of word SSOW in the 
control point area) is examined. If set, a status of the user 
job swapped out is returned because the previous SF.SWPO has 
not completed. This is necessary to eliminate a potential 
timing problem which could result in the user control point 
being rolled out indefinitely. 
** If the subsystem is not found, the completion bit and wait 
response indicator are not set. Abort processing of the 
subsystem handles this case if the UCP was established with 
t he subsys tern . 
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QUEUE PROTECT, QFM UTILITIES 



19 



I/O queue protection and dayfile recovery allows the system to 
recover queues and dayfiles across all levels of deadstart. It 
offers the ability to define the residence of the system 
dayfiles, and to terminate a dayfile and start a new one while 
the system is running. 

For queue recovery, a catalog of the recovered queues is built 
at deadstart (level 0). This feature makes it possible to 
remove files from this catalog and add them to the ac t i ve queues , 
or to remove files from the active queues and place them in the 
List of inactive queues- 



Utility programs are provided to dump and load I/O queues, back 
up queued files, take queues out of the system temporarily, and 
move queued files from one device to another. There are also 
list utilities that list the files on the dump tape (LDLIST), 
list selected inactive queues (QLIST), and list the permanent 
files that were created by DFTERM (DFLIST). 



PRESERVED FILES 

A preserved file is one that is retained through a level 
deadstart. Prior to the I/O queue protect feature, permanent 
files (direct or indirect access) were the only preserved files. 
With this feature, I/O queue files and system dayfiles (system, 
account, and error log) are also preserved files. 



QUEUED FILES 

When a file is placed in the input queue and I/O queue protect 
is enabled, it is placed on a temporary device with an input 
queued file type, and the track linkage for' the file is labeled 
preserved in the TRT. Similarly with output files. 

Active queued files (files with an FNT/FST entry and ready for 
processing) can be made inactive by use of the QREC or QMOVE 
utilities. This procedure releases the FNT/FST entry and makes 
an entry in the inactive queue file table (IQFT) on the disk 
that the file resides. This process is referred to as a dequeue 

The operator can make inactive files active and available for 
scheduling (input files) or printing/punching (output files). 
This procedure makes an FNT/FST entry for the file and deletes 
the IQFT entry on the disk. This process is referred to as a 
requeue . 
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Queued files are placed on any temporary mass storage device. 
The device mask and secondary mask are not considered during 
their al locat ion. 



IQFT ENTRY 

The IQFT is a pseudo catalog file containing a four-word entry 
for each queued file with all of the information necessary for 
re-entry into the FNT/FST at a later time. The format of the 
IQFT entry is as follows. 



59 






35 1 


1 


file name table entry 


file status table entry 


length 
(PRUs/lOB) 


packed date and time 


family 1 


f machine ID 



System sector format flag 

If system sector not formatted 

1 If system sector formatted 



QUEUED FILE ENTRANCE 

The entrance of a queued file into the queue (input or output) 
is preceded by the following. 

• The FST for the file is written into the system 
sector at FSSS (the FST as it exists when the 
file is initially queued). FNSS in the system 
sector contains the FNT (except for the 
control point number). The family name is 
written into location FMSS of the system sector 
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The preserved file bit (the bit set in the TRT 
to indicate this file is preserved over all 
Levels of deadstart) for the first track of the 
file is set in the TRT for the device and the 
checkpoint request is set (bypassed if I/O 
queue protect is disabled). 



QUEUED FILE REMOVAL, 

The following steps are taken when a queued file is removed from 
the queue. 

» The file's tracks are dropped and, if I/O 
queue protect is enabled, the checkpoint 
request i s set . 

• A message is issued to the account file 
identifying the job. 

INPUT files are not considered removed from the queue until 
completion of the job. 

System origin jobs are not protected in the input queue, but are 
protected in the output queue. 

QUEUED FILE RECOVERY 

The actual recovery of queues begins with routine REC scanning 
all available devices and reading system sectors for all 
prese rved f i les . 

REC creates a variable length file on the device it is 
recovering containing a list of all queues recovered. Each file 
recovered occupies a 4-word entry in this file (refer to IQFT 
Entry). This file is known as the IQFT and resides on the 
device only if there are inactive queues on the device. 



The first track of the IQFT is kept in location AC6L of the MST 
(refer to section 2), if one exists for the respective device. 
If an IQFT exists, it is rebuilt on each level deadstart. 
When all files on a device have been requeued, the IQFT is 
released. Only when there are inactive files left on a device 
because of the queue selection does the IQFT file exist. 
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As REC recovers each device, messages are issued for devices 
found with queues. The requeueing of queues is performed by 
routines QREC and QFM. 



DAYFILE RECOVERY 

A dayfile may be present on a device in one of three states; 
active, inactive, or permanent file. An active dayfile 
contains a first track pointer in the MST (location DULL) for 
recovery purposes. An inactive dayfile is a dayfile recovered 
on a device but not made active because a different dayfile was 
also recovered. Word DULL of the MST is formatted as follows. 



59 



47 



35 



23 



11 



DAYFILE 
track 


ACCOUNT 
track 


ERRLOG 
track 


^ 


V/^s 


//// 


w, 



DULL 



Active and inactive dayfiles have first track pointers set in 

the MST which serve the same function for device recovery as the 

preserved file bit. A device may contain only one active or 

inactive dayfile of each type. 

A utility program may be used to terminate a dayfile. The 
termination of an active dayfile makes the dayfile a permanent 
file and starts a new active dayfile. Termination of an 
inactive dayfile results in clearing the MST pointers and making 
the dayfile a permanent file. 
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RECOVERY PROCESSING 

The first dayfile, account, and error Log track assigned by REC 
Is held in that device's DULL MST word. The EOI ••«^J-""" p 
by 1D0 contains the first track to assure a correct BOI/EOI pair 
for validation by RMS on dayfile recoveries. SET passes 
residence information via the dayfile buffer pointers to RMS for 
processing the preserved dayfiles. 

If an active dayfile exists on a device, it is preserved unless 
the device is initialized. Either an INITIALIZE, DF or full 
initialize prevents preservation. Once all dayfiles are 
preserved, the one with the latest date is made the active 
SayfUe! If no dayfiles are preserved, the first system device 
is selected for residence unless directives to SET specify 
otherwise. 

RMS completes the disk chain by reading the dayfile starting at 
the TRT EOI and continuing to the disk file EOI. This is done 
if the file is to be preserved in order to set the correct Last 
sector written. If in the process of computing the TRT nnKage 
a mismatch between the dayfile and TRT reservations is 
discovered, the recovery of the dayfile is discontinued and the 
file space beyond this point is Lost. 

REC updates the FST for the active system, account, and error log 
dayfiles by updating the current track and sector if the file is 
preserved. If the file is initialized, the track chain is 
dropped by RMS. If the file is preserved, the system sector is 
rewritten to indicate last recovery date and time, together with 
the file size. 

The file length is utilized for dayfile dumping to tape options. 
The file length can be used by dump utilities as an indication of 
where to resume dumping on subsequent calls. Dayfiles not 
preserved as active dayfiles remain protected until an 
initialization of that device is performed. 



EQUIPMENT SECTION 



If no dayfiles are recovered, the following CMRDECK entries can 
be entered to select the equipment residence of the dayfiles. 

default of the first system device. 



This overrides the 

DAYFILE = eq,bl 
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ACCOUNT = eq,bl. 

ERRLOG = eq,bl. 

In the preceding entries, eq is the equipment number and bl is 
the CM buffer Length. 

This allows a site to spread dayfiles across several devices. 
The only restriction to dayfile residence is that it must be a 
mass storage, nonremovable device. The eq entry is ignored if a 
preserved dayfile is detected during recovery of the system, but 
the bl entry is always used. 



QUEUE FILE MANAGER (QFM) 



QFM is a PP program which performs many different tasks for 
queue management programs such as QREC and QMOVE. QFM is the 
function processor for all requeueing options, loading and 
dumping queues, and initialization of queues. As QFM reloads 
queues, it issues identifying messages to the account dayfile 

The format of the RA+1 call to QFM is as follows. 



RA + 1 



59 




41 


35 




23 


17 







QFM 


20 B 


fn 





addr 



fn Function code: 

Code Symbol 

1 ATQF 

2 DTQF 



Description 

Attach preserved file (SYOT 
on ly) 

Detach preserved file (SYOT 
on Ly) 
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10 

11 

12 

13 

14 

15 

16 
17 
20 



PGQF Purge preserved file CSYOT 
on Ly) 

STQF Set IQFT file (SSY= required) 

INQF Initialize IQFT file 
(SSJ= requi red) 

RQLF Requeue FNT/FST list 
(SSJ= requi red) 

RLLF Release FNT/FST list 
(SS J= requi red) 

DEQF Dequeue FNT/FST (SSJ= 
requi red) 

AQFF Attach queued file (SSJ= 
requi red) 

QRSF Read system sector (SSJ= 
requi red) 

AIQF Attach inactive queued file 
(SSJ= requi red) 

RIQF Requeue inactive queued file 
(SSJ= requi red) 

SRRF Set rerun protect bit (not 
TXOT) 

CRRF Clear rerun (not TXOT) 

RIFF Release file to input queue 

ASFF Assign file to queue device 



addr Address of the FET 
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The FET for QFM is formatted as follows. 



59 53 47 44 



23 17 13 9 



FET+O 




Ifn 



ec 



Log i ca I file name . 

Error code return (bits 13 through 10): 



Code 


Symbol 


1 


FNFE 


2 


FAIE 


3 


TASE 


4 


FTHE 


5 


INSE 


6 


RMSE 


7 


RRAE 



Pes c ri p t i on 

File not found . 

File already interlocked 

IQFT track a I ready 
as s igned . 

FNT threshold reached. 

Invalid system sector. 

RMS e rror . 

File already protected. 
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cc 
ep 

fp 

eq 
sf 



10 
11 
12 

13 



NRAE 
INFE 
RDVE 

SDVE 



File already unprotected. 

No i nput file. 

Removable device ignored 
(QREC) . 

Shared device ignored 
(QREC) . 



Completion code (bits 9 through 0). 

Error processing bit (bit 44). If set, error 
processing is selected. 

Function parameters. (Refer to entry conditions for 
particular function for required format). 

Equi pment . 
Subf unct i on; 



Code 


Symbo I 


1 


SDAY 


2 


ACCF 


3 


ERLF 


4 


IQFT 



Pes c ri pt i on 
System dayf i le byte 
Account dayf i le byte 
Error log dayfile byte 
IQFT byte 



er 



Mass storage error code. 



QFM is organized as follows. 



QFM main program, resident subroutines, common 
decks, resident function processors 

Overlay 3QA - QFM error processor 

Overlay 3QB - Initialize IQFT file 
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• Overlay 3QC - Requeue/Release FNT list 

• Overlay 3QD - Dequeue/ At tach processors 

QUEUE FILE SUPERVISOR (QFSP) 

The queue file supervisor (CPU program) is the initial processor 
for the queue/dayf i le manipulation utilities. It provides the 
operator with the list of options which are available for 
queue/dayfile processing. The input to QFSP may be either 
through the K display, control statements, or directive input 
file (refer to the NOS System Maintenance Reference Manual for 
more information). All utilities are, however, not callable via 
the K display. 

The following utilities are called via QFSP. 

Utility Desc r i pt i on 

QDUMP Dump I/O queue files 

LDLIST List the queued files on the dump 

QLOAD Load I/O queue files 

QMOVE Move I/O queues from one mass storage 
device to another 

QREC Deactivate or activate selected I/O queue 
files 

QLIST List selected inactive I/O queue files 

DFTERM Terminate an active or inactive dayfile 

and retain it as a direct access permanent 
f i le 

DFLIST List all dayfiles which have been made 
permanent by DFTERM 

QALTER Alter or purge selected queued files 

FNTLIST List selected active queued files 



NOTE 

In the following discussions of 
queue utilities, refer to the NOS 
System Maintenance Reference Manual for 
a complete description of parameters 
and available options. 
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The following tables are built by QFSP. 

• TAR6 - Table of processed arguments. 

• TEQP - Table of mass storage equipment. 

• TSDM - Table of secondary device masks. 

The following words are set by QFSP. 

• FNTA - FNT pointer. 

• DFPA-Dayfile pointer. 

Upon exiting from QFSP ut i I i ty over lays , the following registers 
contain the. indicated information. 

(X2) = 0/ set primary right screen K display 

(X2) < 0, do not change right screen K display 

(X2) > 0, FWA of new right screen K display 

(X5) = FWA of K-display message (message must be 4 
words long) 

CX5) = 0, no K-display message 

(X5) < 0, complement of FWA of K display (do not 
change left screen K display) 

QDUMP/QL0AD UTILITY CONTROL WORDS 

Each queued file and the associated data for the file resides on 
the dump file as a logical record. Each dump session resides 
on the dump file as a logical file, allowing multiple dumps on 
the same dump file. Each block of data is preceded by a control 
word in the following format. 



60454300 A 



19-11 



59 



17 14 11 



name 



name 



Name of queued file if data, or dump file if 
block is dump header (7 characters maximum). 

Logical content of block: 

Data 

1 Route block (5 words plus checksum in 
sixth word which is the arithmetic sum 
of the population counts of the 5 words 
in the route block) 

2 Dayfile (pre-dayfile or regular output 
dayf i le) 

3 NOS dependent data 

4 NOS/BE dependent data 

5 SCOPE 2 dependent data 

6 Dump header (4 words, words 1 and 2 
containing an alphanumeric description 
of the dump, word 3 the date, and word 
4 the time) 

7 Errors (d field is number of errors 
encoun t e red) 

Operating system dependent data (bit 14). For 
NOS (a=3): 

System sector 

1 End of vo lume 
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Structure of data (bits 13 through 12): 

FuL L block of data 

1 EOR (word count is data words plus one 
word which contains the Level number) 

2 EOF 

Number of words in block. 



QFSP is organized as follows. 



QFSP main area (tables, directive input 
processor, directive processor routines, 
command processor, subroutines, default values 
for parameters, and K-display area. 

QFSP ove r lay area 

QDUMP overlay 

QLOAD/LDLIST overlay 

QMOVE overlay 

QREC/QLIST overlay 

DFTERM/DFLIST overlay 



QUEUE RECOVERY (QREC) UTILITY 

The QREC utility provides the capability to deactivate or 
activate selected I/O queue files. QREC deactivates an I/O 
queue file by removing its entry from the FNT and creating a 
corresponding entry in the IQFT file. An IQFT file exists on 
each mass storage device containing inactive I/O queue files. 
I/O queue files recovered across a level deadstart are also 
inactive and are not processed by the system until activated by 
QREC. Typically, the IPRDECK contains a call to QREC and queue 
files recovered across level deadstart are activated 
automatically without operator intervention. An inactive queue 
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file is activated or requeued by removing its entry from the 
IQFT file and making a corresponding entry in the FNT. QREC 
also provides the capability to purge selected inactive queue 
f i les . 

This utility is callable either via the queued file supervisor 
(QFSP) or control statement. 

QREC options include the following. 

• Requeue specified files and purge others. The 
IQFT is searched for the specified files, the 
files are requeued, and the remainder of the 
files in the IQFT are purged. 

• Requeue specified files and ignore others. The 
IQFT is searched for the specified files, the 
files are requeued, and the remainder of the 
files in the IQFT are not affected. 

• Purge specified files and ignore others. The 
IQFT is searched for the specified files, the 
files are purged from the system, and the 
remainder of the files in the IQFT are not 
affected . 

• Dequeue specified files and ignore others. The 
FNT/FST is searched for the specified files. 
The files are dequeued and added to the IQFT 
and the remainder of the files in the FNT/FST 

a re not af f ect ed. 

Entry conditions for QREC include: 

• TARA contains FWA of the parameter table. 

• FNT contains FNTP word from central memory 
res i dent . 

• TEQA contains mass storage equipment table. 



QLIST UTILITY 

The QLIST utility provides a listing of selected I/O queue 
files. This list may include all inactive queue files in the 
system or a selected subset based on options specified when 
ca I I i ng the utility. 
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This utility is part of the QREC overlay. It is called by 
control statement only. 

QLIST accepts all of the QREC parameters except the OP 
parameter. The entry conditions are the same as those for QREC. 

QMOVE UTILITY 

QMOVE is a utility program that moves queue files from one mass 
storage device to another and provides a list of all files 
moved with information relative to each. QMOVE may be called 
either via the console (QFSP) or control statement. 

QMOVE options include: 

• Leave queue files as active files. 

• Leave queue files as inactive files. 

The entry conditions for QMOVE are the same as those for QREC. 

QLOAD UTILITY 

QLOAD processes the dump tapes generated by QDUMP or other 
utilities using the same format. QLOAD can selectively load the 
I/O queues on these dump files. It creates the file on the 
specified device and writes the system sector. QLOAD may be 
called either via QFSP or by control statement. 

QLOAD provides the following options. 

• Load and inactivate. 

• Load and activate. 

The entry conditions for QLOAD are the same as QREC. 

LDLIST UTILITY 

LDLIST provides a list of the queued files on the dump file. 
It can be called only by control statement. The LDLIST 
options are the same as for QLOAD and entry conditions the same 
as QREC. 
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QDUMP UTILITY 

The QDUMP utility dumps selected I/O queue files from a single 
device, a family of devices, or all devices on the system. 
These queue files can be dumped either to tape or mass storage. 
When active queue files are dumped, the FNT is searched to 
obtain the proper file. The IQFT is searched when inactive 
queues are dumped. QDUMP also provides a listing of all files 
dumped. This listing includes information about each file. 
QDUMP may be called either via QFSP or by control statement. 

QDUMP options include: 

• Dump only active files. 

• Dump only inactive files. 

• Dump all I/O f i les . 

Entry conditions for QDUMP are the same as those for QREC. 

DFTERM UTILITY 

The DFTERM utility terminates an active or inactive dayfile and 
retains it as a direct access permanent file for later 
interrogation or processing. When an active dayfile (the current 
system, account, or error log dayfile) is terminated, 
information in the central memory buffer for that dayfile is 
written to mass storage to be included with the permanent file 
and a new active dayfile is started. The new dayfile may reside 
on the same device or a new device may be specified. 

Terminating an inactive dayfile has no effect on the currently 
active dayfiles. Inactive dayfiles are not used by the system. 
Furthermore, the presence of an inactive dayfile in the system is 
possible only under unusual conditions. For example, assume that 
the system is deadstarted and the device which previously 
contained the account dayfile is not in the system (OFF). The 
new account dayfile is then started on another device. Two 
devices now contain account dayfiles. If both devices are turned 
on when the system is next deadstarted, two account dayfiles are 
recovered. The most recent account dayfile is made active and is 
used by the system. The remaining account dayfile is made 
inactive. 

DFTERM may be called either via QFSP or control statement. 
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The DFTERM options include: 

• Terminate active dayfile. 

• Terminate inactive dayfile. 

Entry conditions for DFTERM are as follows. 

• TARA contains FWA of the parameter table. 

• TEQA contains FWA of the mass storage equipment 
table. 

• TSDA contains FWA of the secondary device mask 
table. 



DFLIST UTILITY 

The DFLIST utility provides a printer listing of all dayfiles 
which have been made permanent by the DFTERM utility. DFLIST is 
callable only via control statement. There are no DFLIST 
options. No parameters are permitted on the control statement. 
DFLIST entry conditions are the same as for DFTERM. 



FNTLIST UTILITY 

The FNTLIST utility provides a list of selected active I/O 
queues. These lists may include all active queued files or a 
selected subset based on options specified on the control 
statement, K display, or directive input file. 



QALTER UTILITY 

The QALTER utility provides the capability to change routing 
information associated with active queued files. QALTER may 
also purge active queued files. QALTER generates a list of files 
that were processed. This utility is called either via the 
console (QFSP) or control statement. 



The entry conditions for QALTER are the same as for QREC. 
utility is part of the FNTLIST overlay. 



This 
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ACCOUNTING AND VALIDATION 



20 



This section describes the accounting and validation facilities 
provided by NOS including the following. 

• Account dayf i le 

• SRI) algorithm 

• Validation f i les 

The external characteristics of the accounting and validation 
facilities, and the utilities that interface with them, are 
described in the NOS System Maintenance Reference Manual. 

ACCOUNT DAYFILE 

The account dayfile provides a history of system and resource 
usage. This dayfile serves the following two purposes. 

• Provides the information necessary to properly bill the 
users of the system. 

• Provides the installation with the information necessary 
to analyze the use of the system or any specific part of 
it (for example, magnetic tape usage). 

A standardized message format is provided to aid account dayfile 
analysis. All account dayfile messages have the following 
genera I format . 

hh.mm.ss. jobnameo, geac, info. 



h h . mm . s s 



j o b n a m e 



Current time, beginning in column 2. The 
system appends this field to the beginning 
of any message issued to the account 
dayf i le . 

The name of the job causing the entry of 
this message into the account dayfile. 
The system appends this field to the 
beginning of the message along with the 
time, 

A single character in column 18 which 
describes the origin type of the job. 
This field is automatically appended to 
the jobname and followed with a period. 
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geac 



i nf o 



A unique four character message identifier 
which defines the particular activity 
indentified. This field begins in column 
21 and ends with a comma followed by a 
space. The g identifies the information 
group, the e identifies the event that 
caused the message to be entered into the 
account dayfile, and ac identifies the 
activity being recorded. 

Information that gives further detail to 
the activity identified by geac. This 
field begins in column 27 and ends with a 
period. If a field is not used, it 
appears as a comma and space unless it is 
the last field in the message; then it 
does not appear. 

The individual message groups are described in the NOS System 
Maintenance Reference Manual. Each message is contained in the 
program that issues it to the account dayf i le; NOS does not have 
a common routine for issuing all accounting messages. However, 
the system symbols ACFN and AJNN are used in conjunction with 
calls to PP resident routine DFM to issue the message to the 
account dayfile. Thus, through KRONREF, the routines issuing 
accounting messages may be identified. 

SRU ALGORITHM 

The basic accounting unit of NOS is the system resource unit 
(SRU). The SRU is a measurement of the resources used by a job 
or terminal session. The SRU algorithm combines measurements of 
the following resources into a single unit. 

Central memory field length 

ECS field length 

CPU time 

Mass storage usage 

Magnetic tape usage 

Permanent file usage 

The SRU calculation is dynamic; that is, each time additional 
amounts of the above resources are utilized by the job or 
session, the SRU value is updated. 

The SRU algorithm is: 

SRU = (M1CCP + M2 * 10) + M3CCP + I0)CM + M4CCP + I0)EC) + AD 

Each parameter is defined as follows. 
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Parameter 



Desc ri pt ion 



CP 



10 



CM 
EC 
M1 
M2 

M3 
M4 
AD 



Central, processor usage in milliunits as 
determined by the formula: 

CP SO * CPO + S1 * CP1 

CPO CPU accumulated time in 
mi I li seconds 

CP1 CPU 1 accumulated time in 
mi I li seconds 

S0,S1 Multipliers used to normalize 
CP time when the system is 
running in a dual CPU machine 
or the system is used on 
different mainframes at the 
same site. 

A measure of the accumulated input/output system 
activity for a user. This parameter, expressed 
in milliunits, is defined by the formula: 



10 = S2 * MS + S3 * MT + S4 *PF 

MS Mass Storage Activity 

MT Magnetic tape activity 

PF Permanent file activity 

S2, S3, S4 Mult ipli ers used to 
weight MS, MT and PF 
activity against each 
other 

Central memory field length in words/100B 

ECS field length expressed in tracks 

Multiplier to scale overall SRU value 

Multiplier used to weight I/O activity against 
CP time, CM field length and ECS field length. 

Multiplier used to weight CM field length 
against CP time, ECS field length and I/O 
act i vi ty . 

Multiplier used to weight ECS field length 
against CP time, I/O activity and CM field 
length. 

Adder applied to the SRU value as an 
accumulation of individual unit charges (such as 
utilized at account block initiation and SRU 
accumulation enabling/disabling) . 

SRU multiplier value ranges and default values are defined in 
common deck COMSSRU. The M1 through M4 multipliers and the 
initial AD adder may vary according to charge and project numbers 
and may be changed by a CHARGE statement during the job or 
session. The SO and S1 multiplier defaults may be overridden by 
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the IPRDECK installation parameter CPM. The S2, S3, and S4 
multipliers, however, are fixed at assembly time in COMSSRU, but 
they may be modified to fix the needs of the installation. The 
NOS System Maintenance Reference Manual contains the information 
necessary to adjust SRI) multipliers and how to specify them for 
individual charge and project numbers. 

The account block defines the accumulation of SRUs and other 
resource usage from CHARGE statement to CHARGE statement or end 
of j ob or session. 

The SRU algorithm is contained within CPUMTR and the SRU 
multipliers and accumulators are contained in the job's control 
point area. CPUMTR updates these accumulators and detects 
accumulator overflow conditions. The following CPUMTR 
subroutines perform some portion of the SRU algorithm. 

AAD ROUTINE 

AAD applies the adder increment to SRU accumulator by the 
formula : 

SRU = SRU + AD 

AD is supplied through the UADM monitor function. 

AIO ROUTINE 

AIO applies the 10 increment to SRU accumulator, by the formula: 

10 = S2*MS + S3*MT + S4*PF 
SRU = SRU + I0M*I0 

IOM is determined by CPUMTR routine SRU and S2, S3, and S4 are 
obtained from common deck COMSSRU. AIO is called as the result 
of UADM and TIOM monitor function. 

CPT ROUTINE 

CPT adds the CP time increment to the SRU accumulator by the 
formula : 

CP = S0*CP0 + S1*CP1 
SRU = SRU + CPM*CP 

where CPM is determined by CPUMTR routine SRU and SO and S1 are 
in common deck COMSSRU or overridden by installation parameter 
CPM. CPT is called whenever the control point is given or 
relinquishes the CPU or when the user program asks for the CP 
time through the TIM RA+1 monitor call. 
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SRU ROUTINE 

SRU calculates the SRU multipliers CPM and ION that' are used by 
routines AIO and CPT. The following formulas show the derivation 
of these two multipliers. 

SRU = M1CCP+M2*I0+M3(CP+I0)CM + M4(CP+I0)EC + AD 

= M1(1+M3*CM+M4*EC)CP + M1(M2+M3*CM+M4*EC) 10 + AD 
s (M1+M1*M3*CM+M1*M4*EC)CP + 

(M1*M2+M1*M3*CM+M1*M4*EC)I0 + AD 

= CPM*CP + I0M*CP + AD 
thus 

CPM = M1 + M1*M3*CM + M1*M4*EC 
IOM = M1*M2 .+ M1*M3*CM + M1*M4*EC 




ACCOUNTING CPUMTR FUNCTIONS 

The following paragraphs describe the CPUMTR functions that are 
used for accounting purposes. The subfunctions of these monitor 
functions are defined in common deck COMSCPS. 

ACTM - ACCOUNTING FUNCTIONS 

ACTM performs the following accounting activities. 

ABBF (1) Function 

This function begins an account block by Inserting new 
multipliers in the control point area and applying the initial 
adder'AD to ihe SRU accumulator. The multipliers CPM and IOM are 
calculated. 

This function is used by CPM to begin the .account = blocker, the 
first CHARGE statement and by 1AJ to initialize the job s control 
point area with default multiplier values. 

ABSF (2) Function 

The multipliers CPM and IOM are calculated in this function using 
the current CM and ECS field lengths. 

Routine 1RI uses this function prior to restarting the job. 
ABCF (3) Function 

This function changes or ends the account block by clearing the 
SRU accumulator, replacing the multipliers in the control point 
area! an2 applying the initial adder AD to the SRU accumulator. 
The multipliers CPM and IOM are calculated. 

CPM uses this function to set SRU multipliers for secondary 
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ABEF (4) Function 

Elapsed SRUs (new-old) are calculated and program mode is entered 
with this function for the conversion by RDC. If elapsed SRUs are 
Less than MDSR (defined in COMSSRU), zero is returned. 

Routine 1R0 uses this function when completing a time-sharing job 
s tep . 

ABVF (5) Function 

With this function the accumulators are unpacked and stored one 
per word in the message buffer (MB) and program mode is entered 
for conversion by RDC. If the total SRUs is less than or equal to 
MCSR (defined in COMSSRU), MCSR is returned as the SRU 
accumu lator . 

This function is used by CPM, 1CJ and 1TA to output the 
accumulators at the end of an account block whether it is caused 
by an end of job/session or new CHARGE entry. 

ABIF (6) Function 

The SRU accumulator value is first converted to an integer number 
and then integer addition or subtraction is performed to 
increment or decrement the SRU accumulator with this function. If 
the converted accumulator value is less than 1, 1 is used. 

This function is used by 1AJ in processing SRU limit errors and 
OAU to increment SRU accumulators when updating the PROFILa file. 

RLMM - REQUEST LIMIT 

RLMM sets SRU and time limits for individual job steps. RLMM is 
also used to clear accumulator overflow flags. The functions 
performed by RLMM areas follows: 

Code Funct ion Description 

RLCO Clear overflow flags 

1 RLIT Increment job step time limit 

2 RLIs Increment job step SRU limit 

3 RLJS Start job step 

4 RLTL Set time limit 

5 RLSL Set SRU limit 

TIOM - TAPE I/O PROCESSOR 

TIOM updates the accounting accumulators due to tape I/O 
activity. An increment is specified in the TIOM call to be added 
to the MT accumulator. This increment is applied to the SRU 
accumulator through a call to subroutine AIO. 1MT is the only 
routine in the system that issues TIOM calls. 

UADM - UPDATE CONTROL POINT AREA 

The UADM updates various fields in the control point area 
including the ACLW (counting limits) and the 10 and SRU 
accumulators. UADM performs the following functions. 
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Code 






2 


4 


6 


10 


12 


14 


16 



20 



30 



Funct ion 

LICS 
LIOS 
LDOS 
LDCS 

CICS 
CIOS 
CDOS 
CDCS 

AISS 



AIAD 



Desc ri pt i on 



Inc rement 
Inc rement 
Dec rement 
Dec rement 



low 
low 
low 
low 



core 
core 
core 
core 



field 
field 
field 
field 



by 
by 



one 
one 



Increment control point field 

Increment control point field by one 

Decrement control point field by one 

Decrement control point field 

Increment MS or PF accumulators; 
calls AIO to apply the MS or PF usage 
increment to the SRU accumulator. 

Increment AD accumulator; calls AAD 
to apply the adder increment to the 
S RU accumu la tor . 



Functions 0, 2, 4, 6, 10, 12, 14, and 16 are used by PP routines 
CIO, DSP, LFM, OUT, PFM, 0DF, 1AJ, and 1MA to adjust the counting 
limits maintained in ACLW. 

Function 20 is used by 1AJ to charge for program loading, CIO to 
charge for I/O activity, PFM to charge for its activity, and to 
charge for 1/0 associated with message handling. 

Function 30 is used by CPM (function 53) when enabling SRU 
accumulation; an incremental SRU charge may be specified. 



VALIDATION FILES 

The system validation, and project profile files are used to 
validate user access to the system. Validation defines and 
controls the following: 

• Who can use the system 

• What resources can be used (hardware and software) 

• To what extent these resources may be used. 

Every user of the system must have a valid user number (if 
VALIDATION is enabled). In a batch environment this means that 
the statement following the job statement must be a USER 
statement. This causes the routine ACCFAM to be loaded to process 
the USER statement, verifying that the user number exists. If 
the user number is valid, ACCFAM sets up the validation 
information for entry into control point area words UIDW, ALMW, 
ACLW, and AACW. Subsequent job operations are restricted by these 
validation limits. 

If the user is required to be further validated for accounting 
purposes, a CHARGE statement must be the next statement in the 
job. The CHARGE statement causes the CHARGE routine to be loaded 
to validate the charge and project numbers to which the user is 
charging his activities. 
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Thus, the validation procedure allows the system to: 

• Determine if a user is allowed to use the system. 

• Charge the user for his resource usage. 

• Restrict the user to certain resource usage, including 
denying access to the system when the project's SRU 
limit has been reached. 

• Maintain permanent files for the user and control 
access and security of them by mapping the user's user 
number into a specific user index. 



TREE-STRUCTURE FILES 
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e project profile file, 
les. System routine SFS 

its common deck COMSSFS 
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FILE uti li ties that 
t profile files. SFS is 
files of a given format. The 
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The first word of each record on the file is a control word 
containing sufficient information to describe the data within 
the block. The following shows the format of the control word 
used in the directory level blocks. The second word normally 
contains information used by the processing programs, usually the 
creation and last modification dates. The third word contains 
linkage (random address) to the next logical block on that 
level, if one is present. The remaining words in the block are 
directory entries for directory level records. 



59 




47 




35 




23 




11 





dl 


wib 


wpe 


noe 


fwad 



d I Data leve I 

wib Words in block 

wpe Words per entry 

noe Number of entries in block 

fwad First word address of data 
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A total of 63 words (60 words of entries plus three control 
words) can be used in each block in the directory levels. For the 
data level, the control word should be compatible with the 
control words for the directory levels, but this is not 
mandatory. The remainder of the block can be any length and 
format desired. Because of this flexible format, the processor 
program must perform its own I/O for the data-*level block. 
However, if the data level is constructed similar to the 
directory level records, SFS functions can be used to perform the 
I/O. The information in all levels is maintained in a collated 
sequence. 

The and 1 directory levels correspond to the primary level of 
the tree. The entries in the 0-level consist of the first entry 
(and corresponding random address) of each level-1 block. All 
primary entries can be found in the level-1 directory. This 
method enables a quick access to a given primary -entry- The 
first sector in the file is defined to be the first level-0 
directory block which is linked to the next level-0 block. 
Except for the primary level, there exists one directory level 
for each tree level ' termi nati ng with the data level. 

COMSSFS 

COMSSFS provides the communication between SFS and the processor 
program, SFS processes all directory level blocks but the data 
blocks must be handled by the processor program. 

The following functions are defined in COMSSFS for use with SFS. 
Code Function 



10 
11 
12 
13 
14 



ASCT 
SCIT 



ANBT 
CCWT 
SBTT 
SPBT 
PNAT 
PNET 



DZET 
MWST 
SDFT 
SFTT 
STBT 



Desc ri pt ion 
Input processing functions 

Assemble characters 
Scan for code identifier 

F i le read f unct ions 

Add next block 
Crack control word 
Set block in table 
Set pri ma ry b lock 
Pick next address 
Pick next entry 

File manipulation functions 

Delete zero entries 
Multiple word search 
Set data in field 
Space fill table 
Sort table 

Fi le wri te f unct ions 



15 


BLDT 


16 


RBAT 


17 


UDDT 


20 


WTBT 


21 


MAXT 
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Reset block address 

Update di rectory 

Write table 
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MODVAL AND VALIDATION FILES 

MODVAL is a system utility that is used to create and maintain 
the system validation files VALIDUs and VALINDs. These two files 
are both direct access permanent files catalogued under the 
system user index, 377777B. VALIDUs is accessed as a fast attach 
file by most of its users while VALINDs is accessed by MODVAL as 
a normal direct access file. 

MODVAL creates or updates the validation files either by reading 
a file of input data or by accepting commands directly from the 
operator's console via the K display. When MODVAL is operating 
via the K display, the update (0P=U) mode is assumed. Changes 
made are available to the system for the next USER statement as 
soon as the operations performed on a user number are ended via 
the K-display typein K.END, since update mode works with the 
VALIDUs and VALINDs files directly. Refer to the NOS System 
Maintenance Reference Manual for MODVAL options, parameters, and 
examplesofusage. 

VALINDs FILE 

VALINDs contains a record of which user indices have been 
assigned. It consists of 4210B central memory (60-bit) words, 
each bit representing one of the 377700B (AUIMX) user indices 
available in the system. If the bit is set to 0, then the user 
index is available for assignment to a user number. The value 
AUIMX is the maximum user index for legal login and USER 
statements and is defined in common deck COMSACC. User indices 
greater than AUIMX represent special, user numbers and as such are 
not automaticaly assigned to user numbers by MODVAL; therefore, 
user indices above AUIMX are not represented in the VALINDs file. 

VALIDUs FILE 

The validation file, VALIDUs, contains the user validation 
information which, when referenced through a USER statement, 
specifies the user's access permissions and limits. 

VALIDUs is a tree-structure file indexed by user numbers. The 
data in each level is arranged in alphabetical order with the 
lowest i tern first. 

The zero-level contains a fixed amount of data concerning the 
history of the file, and the first user number (and corresponding 
random address) in each primary level-1 block. 

The next level (level-1 or primary level) of the tree contains 
all validated user numbers with corresponding random addresses 
pointing to the level-2 blocks. All level-1 blocks are less than 
one PRU (64 words) in length and may be linked to other level-1 
blocks if the data that should be contained in one block exceeds 
one PRU. 
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The next level (level-?.) of the tree contains all the user 
validation information associated with the particular user 
number. Level-2 blocks are one PRU (64 words) in length and are 
constructed such that four user validation blocks plus block 
header information are contained in one level-2 block. Figure 
20-1 illustrates the VALIDUs level-0 data block, figure 20-2 
shows VALIDUs level-1 data block and figure 20-3 is the VALIDUs 
level-2 data block. This structure is also defined in common deck 
COMSACC. 



59 



47 



35 



23 17 11 



DATA 1 



wib 



cadb 



noe 



creation 



modification 



random address of next level-0 block 



user number 



random address of level-1 block 



DATA Z 



user number 



random address of level-1 block 



DATA n 



user number 



random address of level-1 block 



t 



J 



cadb 



Random address of available level-2 

b lock, i f nonzero 
creation Creation date 
modification Last modification data 



Figure 20-1. VALIDUS Level-0 Block 
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DATA 1 



DATA 2 



59 




47 


35 


23 


11 







1 


wib 


2 


noe 


3 





random address of next level -1 block 


user number 


random addess of level -2 block 


user number 


random address of level-2 block 


■% 






• 








V 



DATA n 



■» 


• 






user number 


random 


address of 


level 


-2 block 


■» 


• 







T 



Figure 20-2. VALIDUS Level-1 Block 
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59 



47 



35 23 



11 



wib 



arbs 



noe 



ARB 1 



ARB 2 



ARB 3 



ARB 4 



I 







user number validation block, arbs words 



user number validation block, arbs words 



user number validation block, arbs words 



user number validation block, arbs words 



Figure 20-3. VALIDUS Level-2 Data Block 
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Level-0 blocks are created only during a create (0P=C) or 
restructure (0P=R) MODVAL run. During updates (0P=U), changes 
are made only to level-1 and level-2 blocks. If too many user 
numbers are added to one level-1 block, the information overflows 
into a new level-1 block. When this happens MODVAL issues the 
diagnostic LEVEL-1 INDEX BLOCKS LINKED. The validation file 
should then be restructured so as to eliminate the level-1 block 
linkage, thus improving the search time for user numbers 
residing in the linked blocks or for nonexistent user numbers 
which would have resided in the linked blocks. 

USER NUMBER VALIDATION BLOCK 

The user number validation block is ARBS words in length. Four 
of these blocks may be contained in a level-2 block. The format 
of the user number validation block is shown in figure 20-4. 



60454300 A 



20-14 



59 53 47 41 35 29 23 17 



answerback one 



answerback two 



answerback three 



answerback four 




11 5 

user index 



reserved 



project number (informational) 



project number (informational) 



charge number (informational) 



db nf 



si 



cm 



reserved 



of 



ec 



df 



IP 



cc 



cp 



ms 



access control word 



terminal usage 



creation 



modification 



installation area 



installation area 



mt 
rp 
db 
nf 
t L 
sL 
cm 
ec 

lp 
cp 



Maximum magnetic tapes (3 bits) 

maximum removable packs (3 bits) 

Deferred batch index (3 bits) 

Number of Local files index (3 bits) 

Time limit index (6 bits) 

SRU limit index (6 bits) 

Central memory FL index (6 bits) 

ECS FL index (6 bits) 

Lines printed index (6 bits) 

Cards punched index (6 bits) 



Figure 20-4. User Number Validation Block 
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The symbol definitions used in AHDS are: 



Symbo L 



Def i n i t ion 



ds Maximum direct access file size index (3 bits) 

fc Number of indirect access files index (3 bits) 

cs Cumulative indirect access file size index (3 bits) 

fs Maximum indirect access file size index (3 bits) 

sc Security count (6 bits) 

of Disposed output index (3 bits) 

df Dayfile message index (6 bits) 

cc Control statement index (6 bits) 

ms Mass storage PRUs index (6 bits) 

The terminal usage portion of AT WD is defined in as follows. 



59 53 47 41 36 



p 


ro 


X 


tt 


c 


is 


r 



p Terminal parity (bit 59)* 

ro Number of rubouts (bits 58 through 54)* 

x Transmission mode (bit 53) 

tt Terminal type (bits 52 through 48) 

c Terminal character set (bit 47) 

is Terminal initial subsystem (bits 46 through 42) 

r Reserved (bits 41 through 36) 



*Not applicable to network terminals 



60454300 A 



20-16 



The access control word (AAWC) is defined as follows. 

59 47 35 28 23 14 

AAWC 



n 



iob 



rab 



apb 



reserved 



access bits 



n 
tab 
rab 
apb 



24 
25 
26 
27 
28 



Reserved for installation 
Installation application permission bits 
Reserved for future applications 
Application permission bits as follows: 



Bi t App I i cation 



IAF 
RBF 
TAF 
MCS 
TVF 



Definition 

Interactive Facility 
Remote Batch Faci Li'ty 
Transaction Facility 
Message Control System 
Terminal Verification Facility 



access bits 

Bit 


1 

2 

3 

4 

5 

6 

7 
8 

9 

10 

11 

12 

13 
14 



Each bit defined as follows: 



Keyword 

CPWC 
CTPC 

CLPF 

CSPF 

CSOJ 

CASF 

CAND 

CCNR 
CSRP 

CSTP 

CTIM 

CUCP 

CSAP 

CBIO 
CPRT 



Definition 

User can change his password 

User can use ACCESS time-sharing 

commands 

User can create direct 

access permanent files 

User can create indirect access 

permanent f i les 

User can have system origin 

p ri vi leges 

User can access library type (LIFT) 

f i les 

User can use nona I locatab le 

equipment 

User can run with CHARGE required 

User can use auxiliary device 

requests 

User has special transaction 

pri vi leges 

User desires no timeout at 

terminal 

User can use system control point 

(SCP) 

User has special accounting 

privileges 

BATCHIO subsystem privileges 

Protect ECS privileges 



60454300 A 



20-17 



DELETED USER NUMBERS 

If a user number is deleted from the system and the user index 
is returned to the available user indices pool, the permanent 
files associated with that user index are not automatically 
purged. These permanent files will become available to a new user 
who may be assigned to the user index. The permanent files are 
also still available to those jobs that can specify the user 
index via the SUI statement. 

Normally, new users are assigned user indices sequentially so 
user index holes would not be assigned unless the particular 
user index is specified. If a user number is going to be 
deleted from the system, it is wise for the site analyst to also 
purge all the permanent files catalogued under the deleted user 
index; this can easily be accomplished by using the PURGALL 
command under this user index. 

Once the VALINDs bit for a user index becomes set, it remains set 
even if the corresponding user index is deleted. Only during a 
MODVAL restructure (0P=R) are the VALINDs bits reset to zero for 
deleted user indices. If there are several user numbers with the 
same user index (this is accomplished by the use of the FUI 
command), the VALINDs bit for the user index remains set during a 
restructure even if some of the user numbers are deleted. By not 
resetting VALINDs bits for deleted users, MODVAL can guarantee 
that no new user number will be assigned a previously assigned 
(and then deleted) user index, until a MODVAL restructure (0P=R) 
has been performed. This serves to protect a user's permanent 
files from being purged should the user accidently be deleted. 

When a user number is deleted, all the 'pointers for that user in 
level-Q and level-1 blocks are purged. The level-2 entry for 
this deleted user remains in the level-2 block even though there 
are no pointers to it. During a MODVAL restructure (OP=R), these 
level-2 blocks are read and those blocks without level-1 
pointers are eliminated, and if no other user number has that 
corresponding user index, all permanent fi Les catalogued under 
that user index are purged. No permanent files are automatically 
purged until a restructure of the validation files is done. Only 
at that time does MODVAL purge permanent files for those user 
indices specified as unused (deleted) in the VALIDUs file. 

ACCFAM PROGRAM 

ACCFAM is the CP program that processes the USER and FAMILY 
control statement. ACCFAM cracks the USER statement and makes a 
call to CPM to validate and return the validation limits for the 
specified user number. CPM validates the user number and obtains 
the user's validation limits by calling OAV. The validation 
limits returned are entered into the UIDW, ALMW, ACLW, and AACW 
words of the control point area by the SSJ= special entry point 
mechanism when ACCFAM completes. 

ACCFAM also sets the name of the family selected by the system 

origin user via the FAMILY control statement. A CPM function is 

used to enter the family information into the job's control point 
area . 
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ROUTINE OAV 

Routine OAV is used by PP routine to Locate the user number 
validation block of a user number. 

Routine OAV first finds the validation file for the desired 
family, using the default family if no family is specified. 

The level-0 blocks contained in this fast attach permanent file 
are searched until the user number in question is greater than a 
user number found in the level-0 block. When this condition is 
met, the random address portion of the user number entry in the 
block is the location of the level-1 block needed. The entries 
in the level-0 block are structured such that only the first data 
user number entry is each block need be examined if the 
searching criterion is not met by the other entries in the block. 
Thus, once the level-0 search criterion has been met, it is not 
necessary to search more than one level-1 block (unless linked) 
and one level-2 block. 

The level-1 block is then read and searched until the desired 
user number is matched with a user number in the level-1 block 
(or a linked level-1 block). When this match occurs, the random 
address portion of the level-1 entry is the location of the 
level-2 block that contains the validation information for this 
user numbe r . 

The level-2 block is then read and searched until the user number 
matches with an entry in the level-2 block. The address of the 
validation information is then made available to the caller of 
OAV along with the user index assigned to the user number. If, 
during the search, no match is found or one of the random 
addresses is fraudulent, the user index returned is set to zero 
to indicate that the user number could not be found. If the 
user number is found, but the password was not correct or some 
other error was detected (such as secondary user statements not 
enabled and not first user statement for non-SYOT jobs), the 
security count field in the validation file entry is decremented 
and this level-2 block is rewritten to the validation file. 

Routine OAV is called by PP routines CPM, DSP, LFM, PFM, QAC, 
QFM, VEJ, XSP, OVJ, and 1TA. 

Figure 20-5 contains a flow chart of OAV. 
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OAV 



3 
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relocate 
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IVF 



initialize 

validation 

file 
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validation 

file 
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fast attach 

file 
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accounting 

message 



\k 

( return J 



Figure 20-5. Routine OAV 
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The following paragraphs described the main routines in OAV. 
SUN - Search for User Number 

Routine SUN is responsible for reading the VALIDUs file 
searching for a specified user number. Routine SIB <fearch 
index block) is called to search the level and level 1 blocks 
for the user number. SUN either returns the user block or 
returns a user block not found status. 

UVF - Update Validation File 

Routine UVF is responsible for decrementing the security count 
in the user block found by routine UVF. The user block is then 
rewritten to the VALIDUs file. 



IVF 



- Initialize Validation File 



Routine IVF is responsible for finding the correct validation 
file and interlocking it in the correct file mode. The correct 
mass storage driver is loaded. 



60454300 B 



20-21 



VALIDATION LIMITS 

Common decks COMCCVI and COMPCVI convert index values into Limit 
values using concepts called index limit and index table. 

The index limit concept determines an upper limit value from an 
index value by using the index value in a formula. The formula 
usually has the form: 

limit = index * multiplier + default constant 

This technique allows many values to be saved in a minimal amount 
of space. The following resources are limited by the index limit 
concept : 

Resour ce 

Time Limit 

SRU limit 

Li nes pr i nt ed 

Cards punched 

Loca I f i les 

Central memory field length 

ECS field length 

Number of deferred jobs 

The index table concept uses an index value to point to an entry 
in a table which contains the limit value. The following 
permanent file controls are managed in the index table manner: 



Rout i ne 


TLI 


SLI 


LPI 


CPI 


NFI 


CMI 


ECI 


DBI 



Rout i ne 


FCI 


DSI 


FSI 


CSI 



Resour ce 

Number of permanent files 
Length of individual direct access file 
Length of individual indirect access file 
Total length of indirect access files 

A third method of limiting resource usage is the counting 
limit method. In this method, a limit value is established and 
is decremented until it reaches zero, at which point the limit 
has been reached. This limit value may also be incremented as 
charged units of the resource are released. The counting limit 
values are adjusted by the monitor function UAOM 
contained in word ACLW of the control point area, 
used is determined by the index limit mechanism, 
limit method is used to control the following: 



and are 

The limit value 
The count i ng 



Rout i ne 


NSU 


CCI 


DFI 


OFI 



Resour ce 

Mass sto rage PRUs 
Control statements processed 
Dayfile messages issued 
Output files disposed 



The limit values used for magnetic tape and removable pack 
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resources is the actual number entered; there is no formula or 
table derivation of these two validation limits. 

The limit value derivations contained in the two common decks 
may be selectively assembled by including an appropriate D E F 
pseudo instruction prior to the common deck call. The definition 
of the routine name with a $ appended causes that derivation 
routine to be assembled. For example, the sequence: 



CMI$ 
• CALL 



DEF 
COMCCVI 



1 



causes only the CMI (central memory field length limit) routine 
to be assembled. This technique allows all the formulas and 
tables to be maintained in one common deck of each type without 
excessive memory requirements in the programs using the deck. 

PROFILE AND PROJECT PROFILE FILES 

PROFILE is a system utility that is used to create and maintain 
the system project profile file PROFILa. PROFILa is a private 
direct access permanent file catalogued under the system user 
index (377777B) that is normally accessed as a fast attach file. 

PROFILa contains the information required to control a user's 
accounting and access to the system as defined by charge and 
project numbers, with additional limits on time-of-day and 
accumulated resource usage. The user is required to supply 
correct charge and project numbers if the CHARGE not required 
(CCNR) bit is the user's access word (AACW) is clear. PROFILE 
also allows the specificaton of a master user for a charge 
number. This master user is validated to add or delete project 
numbers, user numbers, and user access information for the 
specified charge number. 

ACCESS TO PROFILA 

There are three classifications of access and modification to 
PROFILa: 

• System origin jobs 

• Special accounting users (CSAP bit set in AACW) 

• Master users 

In each case, the former level possesses more capability than 
the latter. 

System origin jobs have complete access to PROFILa, with no 
restrictions regarding PROFILE options and directives. 

Special accounting users from non-system origin jobs have full 
capabilities on update (0P=U) and inquiry (0P=I) PROFILE runs, 
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but may not perform create (0P=C), reformat (OP=R), List (0P=L), 
or source (0P=S) operations. 

Master users from non-system origin jobs may only alter values 
pertaining to charge numbers for which they are the defined 
master user, such as entering users numbers under the number. 
Master users may not change any of the charge installation 
related project number parameters, such as installation 
accumulators, nor may they change any charge number parameters, 
such as the SRU multipliers. Refer to the NOS System 
Maintenance Reference Manual for PROFILE options, parameters, and 
examples of usage. 

PROFILa FILE 

The PROFILa file is a 3 - I e v e I tree-structured file and is 
manipulated in the same manner as the validation file VALIDUs, 
Levels , 1 and 2 are directory levels and level 3 is the data 
level. The data in each level is arranged in alphabetical order 
with the lowest item first. 

The level-0 contains a fixed amount of data concerning the 
history of the file, and the first charge number (and 
corresponding random address) in each primary level-1 block. 

The next level (level-1 or primary level) of the tree contains 
all validated charge numbers and their master users, with 
corresponding random addresses pointing to the level-2 blocks. 
Information pertaining to all projects associated with the charge 
number, such as SRU multiplier indices, are also contained in 
t he leve 1-1 b lock . 

The level-2 block of the tree contains all valid project numbers 
for the corresponding charge number. Along with each project 
number is a random address pointing to the level-3 block. 

The level-3 block contains all the project profile information 
associated with this particular charge number and project number. 
Two entries are contained in one level-3 block. If more than 
thirteen user numbers are specified for a given project number, 
an overflow level-3 block containing only the excess user numbers 
is linked to the original level-3 block. Figures 20-6 through 
20-10 show the structure of the PROFILa file and the contents 
of each level block; this structure is also defined in the common 
deck C0MSPR0. 
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59 




47 


35 


23 


17 


11 







wib 


2 


noe 


3 




( 


D 


creation 


modification 




random address of next level -0 block 


ENTRY 1 


charge number 




random address of level -1 block 


ENTRY 2 


same as ENTRY 1 










• 









ENTRY. n 



t 



same as ENTRY 1 



T 



Figure 20-6. PROFILa Level-0 Block Format 
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ENTRY 1 
CSRW 
CDTW 
CLCW 
CMUW 

ENTRY 2 



ENTRY n 



59 




53 


47 


41 


35 


29 


23 


17 


11 


5 


1 


wib 


5 


noe 


3 





random address of next level — 1 block 


charge number 


d 





pel 


pc 


M1 


M2 


M3 


M4 


AD 


cd 


cex 





ISL 


IR1 


IR2 


IR3 


IR4 


IR5 


IR6 


IR7 


IR8 





master user 


level -2 RA 


same as ENTRY 1 


• 
• 


same as ENTRY 1 


• 



d Charge deactivate flag 

pel Project count Limit 

pc Project count 

Mi-AD SRU mu It ip Li er i ndi ces 

cd Charge creation date 

cex Charge expiration date 

ISL InstaLLation SRU Limit 



i ndex 



IR1-IR8 InstaLLation Limit indices 



Figure 20-7. PROFILa LeveL-1 BLock Format 
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1 


59 




47 




35 


23 


17 




11 









2 


wib 


3 


noe 


3 









random address of next level -2 block 


ENTRY 1 


project number (first 10 characters) 




project number (second 10 characters) 




a 







level 


-3 RA 




ENTRY 2 




same as ENTRY 1 


«. 


r 








• 
• 















ENTRY n 



t 



same as ENTRY 1 



a = signifies that the Level-3 block has 1 entry and a 
signifies that the level-3 block has 2 entries. 



= 1 



Figure 20-8. PROFILa Level-2 Block Format 
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59 53 47 41 35 29 23 17 



PRJN 

PCHW 
PCDW 
PTMW 
PCGW 
PMSW 
PUDW 
PISW 
PIRW 



PUNW 



3 


ne 


un 





next ra 


project number (first 10 characters) 


project number (second 10 characters) 


charge number 


cd 


pex 


reserved 


d 


reserved 


ti 


to 


isv 


Icdate 


reserved 


sml 


sma 





ludate 


lutime 


sil 


sia 


LR1 


AR1 


LR2 


AR2 


LR3 


AR3 


LR4 


AR4 


LR5 


AR5 


LR6 


AR6 


LR7 


AR7 


LR8 


AR8 


reserved 


user number 1 





• • • 

—f{— 


• 
• 


user number n 






The above format is repeated if there is a second entry in the 
level-3 block. 

Figure 20-9. PROFILa Level-3 Block Format 
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ne Pointer to next entry in the block 

un Number of users in the project 

ra Random address of first overflow block 

cd project creation date 

pex Project expiration date 

d project deactivate flag 

t i Time in 

to Time of f 

isv SRU validation limit index 

ledate Last change data by PROFILE update run 

sml SRU master user limit 

sma SRU installation limit 

ludate Last update date by OAU 

lutime Last update time by OAU 

sil SRU installation accumulator (updated by OAU) 

LR1-LR8 Installation limit registers 

AR1-AR8 Installation limit accumulators 



Figure 20-9. PROFILa Level-3 Block Format (Continued) 



59 


53 






17 







OV 





next ra 


user number n+1 









. • 


s 


■» 


• 
• 


V. 




Figure 20-10. PROFILa Level-3 Overflow Block format 
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DELETED CHAKGE AND PROJECT NUi'IBERS 

Charge, project, and user numbers may be deleted from the PROFILa 
file; however, on Ly the user numbers are physicaly removed from 
the file when deleted. A bit is set in a deleted entry to signify 
that the entry is no longer active. When a reformat PROFILE 
(QP=R) operation is performed, the entries that were marked as 
deleted are excluded in the restructuring. 

CHARGE ROUTINE 

The system routine CHARGE provides validation of a user's charge 
and project numbers for access to defined amounts of system 
resource usage measured in SRUs. A call to CHARGE is required 
for all users if the CCNR bit is not set in the user's access 
word (AACW). 

If the validation of the user's charge is not successful, the 
job is aborted with an appropriate diagnostic. The validation is 
unsuccessful if the charge or project numbers are not found, the 
user is not validated to use the charge or project number, or 
the charge/project has reached its SRU limit. 

If the validation is successful, then 

1. Appropriate information is written to the account 
dayfile (ACCOUNT) indicating the user's charge and 
p ro j ect numbe rs . 

2. Accounting parameters (SRU multipliers and the SRU 
validation limit for the account block associated with 
the user's charge and project number) are entered into 
the job's control point area via a CPM function for 
usage in the accounting formula. These values are used 
until the end of job or session or until another CHARGE 
statement is issued. 



3. The accumulated SRUs (or the minimum installation 
charge, if larger) are entered into the accounting 
dayfile and OAU called to update the SRU accumulator 
this charge/project/user in the PROFILa file. This 
occurs only on the second and subsequent CHARGE 
statement s . 



for 



4. The SRU accumulator in the control point area is 

cleared but the AD, CP, MS, MT, and PF accumulators are 
not affected. 

ROUTINE OAU 

Routine OAU updates the level-3 block for the charge/project 
number when the job's SRU accumulator overflows or at the end of 
an account block. This mechanism allows the information contained 
in the level-3 block for the charge/project number to be as 
up-to-date as possible. The equipment, track, and sector of the 
level-3 block for the project number is kept with the accounting 
words in the control point area; this allows fast access to the 
PROFILa file by OAU. 

Routine OAU is called by the PP routines CPM, 1AJ, 1CJ, 1R0, 1SP, 
and 1TA. Routine OAU is flowcharted in figure 20-11. 
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RLMM 



clear 
overflow 
flags 



IOM 



issue 
overflow 
messages 




set 

completion 

status 



c 



return 



drop 
channel 




Figure 20-11. Routine OAU 
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no 



return 




set sector 
position 



RCH 



request 
channel 



POS 



position 
disk 



RDS 



read disk 
sector 



yes 




set 
current 
SRU 
accumulator 



set master/inst. 
accumulator, 
increment value 



ACTM/ABIF 

update 
account 
block 





set 
normal 
completion 





set incremented 
values and 
current time 
and date 



no 



RCH 



request 
channel 



POS 



position 
disk 



WDS 



write disk 
sector 




yes 



Figure 20-11. Routine OAU (Continued) 
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PRS 



set jobname 
dayfile messages; 
set SRU/job name 
parameter address 



move 

job name 

to message 

area 



set level-3 

sector 6* track; 

set PROFILa 

FST address 




DELAY 



no 



yes 



yes 




yes 




set function 

code and 

TELEX flag- 



set equip- 
ment number ; 
read PROFILa 
FST entry 



set error 
code 



EXIT OAU 



set error 
code 
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Figure 20-11. Routine OAU (Continued) 
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DATA BASE ERRORS FROM PROFILE 

PROFILE issues a diagnostic message in a variety of conditions 
that normally should not occur. Th is di agnos t i c has the form: 

DATA BASE ERROR nn - NOTIFY ANALYST. 

The following errors will prompt this message to be issued. 

nn Description (routine) 



1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

30 

31 

32 

33 

34 

38 

39 

40 

41 

42 

43 

45 



Bad 

Bad 

Nega 

Bad 

Bad 

Exi s 

Exi s 

Ex i s 

Ille 

Bad 

Exi s 

Exi s 

Bad 

Bad 

Bad 

Bad 

Bad 

Bad 

Bad 

Bad 

Bad 

Bad 

Ille 

Bad 

Bad 

Nega 

Badl 

Bad 

Bad 

Bad 

Bad 

Bad 

Bad 

Bad 

Bad 

Bad 

Bad 

Bad 



tab le 
ove rf 
t i ve 
queue 
leve I 
t i ng 
t i ng 
ting 
gal K 
leve I 
ting 
ting 
leve I 
leve I 
table 
table 
table 
level 
leve I 
leve I 
leve I 
rando 
gal f 
level 
queue 
t i ve 

leve 
user 
user 
ove rf 
Leve I 
Level 
Leve I 
Leve I 
Leve I 
Leve I 
Leve I 
Leve I 



2 p 

low 

proj 

poi 

o 

char 

char 

proj 

di s 

o 

char 

proj 



-3 

-3 

3 

3 

3 

-3 

-3 

-3 

-3 



m ad 
i e Id 
-3 b 

poi 
user 
1-0 
numb 
numb 
low 

o 





-2 

-2 

-0 

3 

3 





oi nt 

b loc 

ect 

nter 

r 1 

ge n 

ge n 

ect 

play 

r 1 

ge n 

ect 

lock 

loc k 

engt 

oi nt 

oi nt 

lock 

lock 

lock 

lock 

dres 

s i z 
lock 
nter 

num 
b loc 
er p 
e r p 
b loc 
r 1 
r 1 
lock 
lock 
lock 
engt 
oi nt 
r 1 



er (P 

k poi 

count 

(MQE 

block 

umbe r 

umber 

numbe 

upda 

block 

umber 

numbe 

CPDE 

(PDE 

h CW0 

er (W 

e r CW 

CADB 

(ADB 

(ADB 

(CEP 

s (RD 

e (GF 

(RDB 

(DQP 

ber c 

k (PR 

oi nte 

oi nte 

k (NU 

block 

b lock 

(PEI 

(PCS 

(PL0 

h (FU 

er (F 

block 



DE 

nt 
( 

) 
( 
n 
n 

r 

te 
( 
n 

r 

) 

) 

B) 

0B 

0B 

) 

) 

) 

) 

B) 

V) 

) 

) 

ou 

F) 

r 

r 

E) 
( 
( 

) 

) 

) 

H) 

HP 
( 



) 

er (PRF) 

UPC) 

RCE) 

ot found (RCE) 
ot found (CNP) 
not found (PNP) 

(CKU) 
CNP) 

ot found (CNP 
not found (PNP) 



nt (DUN) 

(NUE) 
(NUE) 

PI0) 
CND) 



) 
DQP) 
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MMF OVERVIEW 

Multimainframe (MMF) enables up to four computers to access 
shared mass storage devices. This allows the ma inf ra ■•» ^ "Jj^ 
preserved files residing on such devices. Each mainframe in the 
comolex can operate in mu It imai nf rame mode or in stand-alone 

°ode however two machines cannot -cess the same device un ess 
both are in mult imai nf rame mode. A device is considered shared it 
i? can be accessed by more than one of the mainframes. It need 
not be accessible to all the mainframes in the complex. 

ECS is used as the means and media for controlling shar ed mass 
storage and inter-mainframe communication. Each ma inf ra ^ has a 
CpS port into ECS which is utilized by CPUMTR to cont ro y em 
activity. The ECS flag register is used as the first I of 
interlock among the machines accessing tables in ECS. ™ es « 
iables such as the TRTs for all shared mass storage devices, 
contain lower levels of interlocks in order to provide the same 
controls that exist in a standalone environment. 



In order 
resi dent 
cont a i ns 
device n 
shared) 
each dev 
machi ne, 
memory r 
machi ne 
device, 
there ar 
detai led 
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tab 
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des 
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ent 
very 

is, 
inf r 
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rol 
are 
i cal 
f ea 
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ed m 
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re a 
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ass 
. A 
t i on 
stor 
y an 
is t 
s st 
T, a 
exi 
s ma 
comp 
e ta 



storage devices, several ECS 
device access table (DAT) 

(family name/pack name and 
age device (shared and non- 
y machine in the complex. For 
o be accessed by more than one 
orage table (copy of central 
Iso reside in ECS. In addition, 
sts in ECS for each machine and 
ny MRTs for each shared device 
lex. Section 2 contains a 
b I e s . 



as 



The interlock for a device is a word in the ECS resident MST. 
When a machine is going to update an "ST/TRT, it jus : p ace its 
machine mask in the interlock word of the MST. The writing ot 
this interlock word is controlled by the ECS flag register. Only 

h he S machine which has a bit set in ^e ECS flag register may 
interlock a device. CPUMTR controls all interlocks. 
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es , 
n a 
f a 
mult 



e to either join other machines 
ame environment, or to come up in a 
lone system will not be allowed to 
vices as other machines. Every effort 

detection of this situation; 
to provide a 100 per cent guarantee 
vated, and access a device currently 
The existing levels of recovery (1, 
multimachine environment. Methods are 
system interruption to operate the 
imainframe environment. 
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MMF ENVIRONMENT 

Any combination of from two to four 6000, Lower CYBER 70, or 
CYBER 170 mainframes may comprise an MMF environment. ECS is 
required, with one CPU port for each mainframe. The presence of 
a DDP on a CPU port decreases by one the total number of 
mainframes that may run together. The 841, 844, and ECS devices 
are the only devices that are supported as shared devices. 

If ECS is being placed in maintenance mode (MA parameter set in 
EQ=entry), a full level deadst art' must be performed. The size 
of ECS is automatically reduced by half at deadstart. The 
remaining half of ECS is available for ECS on-line diagnostics. 



SYSTEM FLOW 

Automatic detection of ECS is not provided because it is not 
possible to determine its absence and continue to run on all 
machine types. The 6600 CPU will hang if an attempt is made to 
execute an ECS instruction without any ECS. ECS status is 
checked by CMR (SET) when called upon to process an ECS entry 
in the CMRDECK. If the CMRDECK entries are present which 
indicate a multimainframe environment, a check is made to insure 
that either a DE or DP equipment entry is also present. If none 
is found, an error indication is given to the operator that no 
Link device has been defined. The link device is automatically 
designatedasashareddevice. 



DEADSTART 

At deadstart time each machine must be given a two-character 
machine identifier (MID). This CMRDECK entry must be unique for 
each machine in the complex. The purpose of this identification 
is to associate a specific machine with its access to a shared 
device. There are no external characteristics associated with this 
i dent i f i cat i on. 

When a mainframe joins a complex it is necessary to associate it 
with an identification that it can Utilize as Long as it is up 
and running, but which is also independent of the MID it has 
chosen for itself. During the deadstart process a machine 
investigates the MMF tables residing on the Link device to find 
a slot (of which there are four) that currently is not being 
used by another machine. Once an empty slot is found, the MID 
is placed into it. Associated with each slot is a unique machine 
index and a unique machine mask which the machine uses to index 
itself into various MMF tables or to i dent i f y i tse If in these 
tables. The indices are 1, 2, 3, and 4; whereas the masks are 1, 
2, 4, and 8 . 

In the deadstart process, if level has been selected, it is 
necessary to determine if this is a global deadstart (first 
machine up in an MMF complex). The machine performing a global 
deadstart presets certain tables in ECS, and in so doing assures 
that no other machine has arrived at the same point in the 
deadstart sequence and is attempting the same thing. These 
operations are performed by the PRESET segment of CPUMT'R. 
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One of the functions of a machine operating in a mu It imainf rame 
complex is to pe ri odi ca I Ly copy its system time into the MMF 
environment table. This mechanism provides a real time 
determination of how many systems are working together. 
Determination of which machines are running in the MMF 
environment can therefore be accomplished by having CPUMTR read 
the ECS table of system clocks, and then detect a change in the 
information written. Whenever CPUMTR goes through its advance 
running time routine (once per second), it also interrogates the 
flag register and updates its ECS system clock. Every second 
time, CPUMTR check the clocks of the other machines and sets an 
indication in MMFL (refer to section .2) as to which machines are 
currently active, and which machines have been active but are not 
currently. Once an inactive machine becomes active again, the 
MMFL status is reset to indicate that that machine is active. 

Preset of ECS involves the initialization of the DAT and the MMF 
environment tables (refer to section 2). It is Imperative that 
the link device (ECS) be initialized at deadstart time if it has 
not been previously used as a link device. When initializing 
the DAT, enough tracks are allocated to handle the maximum number 
of shared devices that can be supported in the complex. 

The first machine deadstarted in a complex must have the PRESET 
multimainframe command entered when deadstart i ng . This machine 
clears the flag register and sets the interlock in the flag 
register indicating preset in progress (ECS resident is beang 
preset). All other machines deadstarted in the complex should not 
have the PRESET mu It imainf rame command entered at deadstart time. 
They interrogate the flag register for an interlock bit, which, 
among other things, indicates deadstart in progress. If they 
find it, a message to this effect is displayed until the inter- 
lock is cleared from the flag register by the presetting machine 
and then this machine proceeds with its deadstart process. 



A machine that does not preset ECS cannot determine if it has 
already been preset by another machine. Therefore, the operator 
must insure that ECS has been preset by a prior deadstart before 
deadstarting a particular machine without presetting ECS. 



is not the same as 
If a machine has 



A check is also made to ensure that the MID 

any machine already running in the complex. 

already specified the same MID, the deadstart process on the 

second machine halts and displays a 



message . 



RMS 



Any errors encountered before DSD is running are passed to 
as error codes. RMS translates these error codes to messages 
and displays them. 



ma i nt ai ned 



SHARED MASS STORAGE 

For purposes of device usage determination, tables are 
in ECS that identify the status of all devices in the mult imam- 
frame complex. This includes shared and nonshared devices for all 
machines. These tables are called the device access tables (DAT). 
^ L _ x. *. ~* *w« r»AT 4e -illustrated in section 2. 



The format of the DAT is illustrated in section 
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In order to minimize configuration problems, all shared removable 
equipments should be configured the same on all machines in the 
complex. For example, if one system defines three shared units as 
three DI-1s and another system defines the same units as a DI-3, 
the first system can accommodate a DI-2 on these units whereas the 
second system would find it as an error situation. Unless the 
configurations are the same on all machines, any devices mounted 
on those drives may not necessarily be recoverable on all 
mach i nes . 

RESEX considers only the configuration of the machine it is 
executing on in its overcommitment algorithm. 



MASS STORAGE RECOVERY TABLES 
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The meaning of the MRT bit, if set, depends upon the state of 
the track interlock bit for the same track in the TRT. 



T rack 
interlock 
bi t 



MRT 
bit 



D e s c r i p tio n 











Track not interlocked or it is local to 
anot her machine 



Indicate first track of a file local to 
this machine 



Track is interlocked by another machine 
Track is interlocked by this machine 



Track interlocks are set and cleared in the following manner: 
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When the MRT bit denotes the first track of a local 
file: 

a. MRT bit is set for the first track when tracks are 
initially requested for a file. 

b. MRT bit is cleared when the preserved file bit is 
set . 

c. MRT bit is cleared when the first track of a track 
chain is dropped . 

When the MRT denotes that a track (preserved file only) 
i s interlocked: 

a. MRT bit is set when track interlock bit is set. 

b. MRT' 'bit is cleared when track interlock bit is 
cleared. 

c. MRT bit is cleared if the track is the first track 
of a track chain being dropped. 



The purpose of the MRT is the recovery by the remaining machines 
of a down machine's mass storage space and interlocks. This MRT 
processing is one of several things that must be performed to 
recover shared devices from an interrupted machine. (The whole 
area of machine recovery is discussed in more detail later in 
this section.) Briefly, the steps required to process an 
interrupted machine's MRT are as follows: 

1. Secure the device interlock to insure that another 
machine is not attempting the same recovery. 



2. 
3. 



4. 



7. 



Read in MRT for device and machine being recovered. 

For each MRT bit that is set, the following is done 
depending on the state of the corresponding track 
interlock bit. If the track interlock bit is set, this 
track was interlocked by the down machine. Clear the 
track interlock. 

Rewrite the MRT with bits cleared for those tracks 
whose interlocks were released. Clear the device 
interlock (ACGL). 

If MREC is then called, it secures the recovery 
interlock (DATI) to insure that another MREC is not 
attempting the same recovery. 

Read in the MRT for the device and machine being 
recovered. 

Then, for each MRT bit that is set, do the following. 
If the track interlock bit is not set, this track was 
the first track of a file local to the down machine. 
The track chain is dropped. A verification is performed 
to insure that the chain is indeed local and reserved. 
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TRT INTERLOCKING 

CPUMTR interlocks and updates its copy of the MST/TRT for DLKM, 
DTKM, STBM, and RTCM (AMSM) monitor functions. There is an 
option on the STBM function to indicate that the MST/TRT 
should be updated. The way these functions interlock an MST/TRT 
is as f o I lows . 

1. The device is determined to be shared (indicated by the 
presence of an ECS address in the MST) . 

2. CPUMTR attempts to secure the flag register interlock 
(TRTI) . 

3. If CPUMTR successfully sets the flag register interlock, 
it then attempts to interlock any MST/TRT. This is done 
by placing its machine mask in the SDGL location in the 
MST. If this location already contains a machine mask, 
CPUMTR clears the flag register interlock, rejects the 
request, and exits to handle other requests. 

4. If CPUMTR can set the MST/TRT i nter loc k it then 



rewrites the first three words 
with its machine mask in SDGL. 
interlock is then released and 
in the TRT and global MST. 



of the MST out to ECS 

The TRT flag register 
CPUMTR is ready to read 



5. A check is made to see if the MST/TRT has been updated 
since this machine last obtained an up-to-date copy. 
If it was not, the TRT need not be read in. At this 
point the MST/TRT is interlocked with the current copy 
in CM and it can continue processing the monitor 
function. When the monitor function is completed the 
TRT is updated. A field in SDGL is incremented 
indicating that this was the last machine to update the 
MST/TRT, thus making this device available for others 
to allocate on. The first three words of the MST are 
then written out to ECS (with the MST/TRT interlocked - 
cleared) making this device available for" others to 
allocate on. The interlock word is the last of any 
global words written to ECS. 



6. Separate steps must be taken if 
the required interlocks. 



CPUMTR cannot secure 



DEVICE INITIALIZATION 

In order to initialize a shared device, it is necessary to 
prevent any new activity from starting on the device. The next 
step is to wait until all current activity has completed. Once 
it is detected that all activity has subsided on the device, the 
device is interlocked and initialization proceeds. The following 
steps must be taken to accomplish this set of tasks. 
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First, the INITIALIZE command should be entered on the machine 
from which the initialization is to take place. All other 
machines sharing the device need to unload the device (enter the 
UNLOAD command) in order to prevent any new activity. The 
INITIALIZE command sets the initialize bit in this machine s 
local portion of the MST. If when attempting to set this bit 
it is found that another machine already has its initialize bit 
set, the operation will not be performed; instead, an error is 
displayed at the system control point. 

Next, IMS, on the machine with the i ni t i a I i ze set, monitors the 
status of the other machines that are sharing the device. Once 
each of them has their unload status set and all user counts are 
zero, initialization proceeds. 

When the device is free for initialization, the device is 
interlocked and the current TRT is obtained from ECS. After 
initialization is complete, the MST/TRT is updated in ECS and 
the checkpoint request bit is set in the MST. The initialization 
bit is then cleared. Routine 1CK is then called to checkpoint 
the device. The initialization process includes updating of the 
DAT entry (if necessary). 

In order to activate the device on other machines, the operator 
must mount the device. The MOUNT command clears the unload 
status. If initialization is still in process on another 
machine when a MOUNT i s attempted, the MOUNT process is 
terminated with an error displayed at the system control point. 
(The recovery of the device that occurs at this point is the 
same as items 3 and 11 in the recovery matrix in table 21-2.) 



DEVICE UNLOAD 

UNLOAD from any machine sets the local unload bit in the MST for 
this machine only. This is an indication to this machine that 
no new accesses should be initiated. If the intent of the 
unload is to eventually physicaly unload the device, then an 
unload must be entered on each machine sharing the device. When 
CMS on any machine checks a device and finds that all locaL 
unloads are set andall user counts are zero, it then sets the 
global unload only if the device is a removable device. The 
global unload is displayed to the operators on all machines 
indicating that there is no activity on the device from any 
machine and that the device may be physically unloaded. 

When a CMS detects that it can set the global unload and does 
so, it also clears the DAT entry in ECS. 




MOUNT comm 



and does nothing if the local unload is not set. 
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ft. VxCcKfcCUtfcrir 

RMS and CMS use similar Logic in recovering mass storage devices. 
When a device is recovered, the DAT is interlocked while a check 
is made to see if an entry exists for this device. The 
presence of an entry indicates that another machine is also 
accessing the device. If an entry is found, and the machine 
recovering the device has not been instructed to share it, an 
error is indicated and recovery halts with an appropriate message 
displayed. If the machine already accessing the device is not 
allowing it to be shared, (TRT is not ECS resident), the same 
error condition is detected. These situations are illustrated 
in table 21-1 . 

The statuses across the top indicate in which mode the device 
is being: ut i li zed. The statuses down the left side indicate in 
which mode a machine coming up wants to utilize the device. 



TABLE 21-1 



DEVICE ACCESS STATUS 



Devi ce used i n 
nonshared mode 



Device used in 
shared mode 



Use devi ce i n 
nonshared mode 



ERROR 
2 mach ines want to 
use the same device 
in nonshared mode. 



ERROR 
Machine comi ng up 
wants to use a 
device in nonshared 
mode that other 
mach i nes a re 
sha ri ng . 



Use device in 
shared mode 



ERROR 
Machine comi ng up 
wants to use a device 
in shared mode that 
anot he r machi ne is 
using in nonshared 
mode . 



Add accessi ng 
status to DAT 



When a machine recovers a device, it adds an indication to the 
DAT entry, if the indication does not already exist, that this 
machine has accessed (recovered) this device. 
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If the device is shared and another machine has it interlocked, 
a bit in the DAT is checked to determine if a Level type 
recovery is in progress on the device. Once the recovery is 
completed, recovery on this machine proceeds as indicated below 
It is not allowable to attempt a non-level recovery on an 
interrupted machine once MREC is run on another machine to 
recover the mass storage space of the interrupted machine. 
RMS recovers a device on a non-level deadstart, the DAT 
indicates that this machine has accessed the devi ce ^previously . 
This status is cleared by the machine recovery utility. 



When 



It is the responsibility of each machine to recover its own 
local MST area from the device. The manner in which the local 
information is maintained on the device is detailed under 
Device Checkpoint. A bit in the global portion of the MST 
indicates if the sector of local information exists. In any 
event, if the local area that exists in the label sector matches 
the MID of the recovering machine, that local area is assumed to 
be the most up-to-date regardless if information also exists in 
the sector of local areas. 



A 
as 



level 3 deadstart assumes that the ECS MMF tables are 
well as CMR when running in a mult imainf rame complex 



intact 



If no entry for the device to be recovered exists in the DAT, an 
entry is made by RMS. A flag register interlock is set to 
prevent other machines from attempting the same. Once recovery 
is completed, the flag register inerlock is cleared by REC. 

Table 21-2 shows the steps involved for mass storage device 
recovery during the various levels of deadstart. When a device 
is not shared with any other mainframe, it is termed a stand- 
alone device. If the device is shared, the DAT is interrogated 
and recovery proceeds differently depending on whether i t i s 
active Cin the DAT) or not active (not in the DAT). Another 
criterion that denotes which steps are taken is the machine mask 
field in the DAT which indicates either that the device has been 
accessed previously by this machine or that the device has not 
been accessed previously by this machine. Removable devices 
recovered on-line are handled the same as devices on a level U 
deadstart. 
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TABLE 21-2. MASS STORAGE DEVICE RECOVERY 



| \ | Stand I Shared- | Shared- I 
j \ Device I ALone I not I active I 
j \ Type | Device I active I I 
I Level \ j | (not in | (in | 
| of \ I I DAT) j DAT) | 
| Deadstart \ I I I I 


| |2,4,6, 11,4,6,7, |3,11 |-device not 

| |7,8,14 |8,9,10,14| laccessed 

| j j j IpreviousLy 

j | n.a. I n.a. 111,12, j-device accessed 

j j j 1 1 3 | previ ous Ly 


| 1 and 2 |2,4,7 1 1 ,4,5,7,9 1 3,1 1 |-device not 

j | | | | accessed 

j || || previ ous Ly 

j |4,7 j n.a. |11,13 |-device accessed 

j || | | previ ous Ly 


j 3 jerror jerror lerror |- device not 

j | j | laccessed 

j j j j jpreviousLy 

| |4,7 j n.a. J11,13 |-device accessed 

j j j j IpreviousLy 



1. DAT entry not found; make DAT entry which indicates 
that this machine onLy is currently accessing the 
devi ce . 

2. DAT entry not found; make DAT entry which shows that 
this machine is accessing the device but has no MST 
pointer (not shared). 

3. Add indication to existing DAT entry which shows that 
this machine is accessing the device. 

4. Retrieve MST (all Local and global portions) from the 
device and, if shared device, preset into ECS. Retrieve 
TRT from devi ce . 

5. Set MRTs from device into ECS. 

6. Edit TRT (release all track chains except the preserved 
f i le chai ns) . 

7. Clear track interlocks for all machines. 

8. Clean up system sectors (interlocks and user counts) 
for all mach i nes . 
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9. Set TRT from device into ECS. 

10. Clear MRTs for all machines. 

11. Retrieve TRT and global MST from ECS. Get local MST 
from device. Clean up local MST (clear interlocks, 
reservations and request statuses). 

12. Process MRT for this machine and drop local tracks. 

13. Process MRT for this machine and clear track interlocks 

14. Build file of inactive queued files. 



DEVICE CHECKPOINT 

Routine 1CK checks for checkpoint requests in the local portion 
of the MST. If a device is not shared, the checkpoint proceeds 
as for standalone systems, if the checkpoint request bit is 
set. If a device is shared, and the request bit in the local 
area of another machine is set, no action is taken. (This 
situation arises when another machine accomplishes the requested 
checkpoint because the checkpoint bit is set in its local area.) 

If the checkpoint request bit is set, it is cleared and the 

local TRT and MST updated from ECS (if necessary). The global 

portion and local portion of the MST as well as the TRT are 
checkpointed to the device. 

The local MST information for all machines is maintained on the 
device. All of this information is kept in one sector on the 
label track following the TRT sectors. This requires a read and 
a write to update the sector which means updates (checkpoints) 
must be minimized and therefore performed separate from normal 
TRT checkpoi nt s . 

The format of the two-word entries in this sector is as follows. 



59 




47 




11 







mid 


reserved 


auc 


DULL word of MST 



mid Machine identification 
auc Active user count 
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A maximum of 37B entries can exist. 

Whenever a field in the Local area of the MST is updated which 
requires checkpointing (currently only those fields of word 
DULL), those programs that perform the update make a call to 1CK 
This 1CK function reads up the sector, searches for a MID match, 
and then updates the existing entry or adds one if none exists, 
and finally rewrites the sector. Bit 6 of word ACGL of the MST 
indicates whether or not the sector exists yet. 



FAST ATTACH FILES 

The concept of fast attach files is to move the access control 
and interlock mechanisms for highly accessed, system, direct 
access permanent files, from the mass storage device into the 
FNT. This provides a much quicker access to the information on 
these files primarily by eliminating several disk accesses (six 
for the normal ATTACH/RETURN sequence) each time the file is 
accessed. To provide accessibility to all machines, this 
information must either be maintained on the mass storage 
device (shared) or in ECS (link device). Putting the 
information back on the device eliminates the benefits of fast 
attach and is therefore undesirable. By placing the control 
information into ECS some overhead is added to the file access 
sequence but it is minimal compared to having it on the 
devi ce i t se If . 

Eight-word tables are maintained on the same track in ECS as the 
DAT for each fast attach file. Within this eight word table are 
the file name, family name, and five words of access and control 
information that are laid out identically to words 20B through 
24B of the permanent file system sector. Each machine keeps its 
access and control information separate but looks at all words to 
determine the current state of the file. There is a limit of 77B 
fast attach entries. 

The monitor function (IAUM) provides the means for interlocking 
the fast attach file when operating in standalone mode. When 
operating shared mode this interface extends to accessing and 
updating the information in ECS. 



PERMANENT FILE UTILITIES 

The PFNL word in CMR is used to keep track of permanent file 
activity and also to control that activity. A dynamic count is 
maintained in this word to account for the number of 
PFMs/PFDUMPs that are currently accessing permanent file devices 

For this purpose, PFM and PFDUMP utilize this word in the same 
manner. PFM and PFDUMP determine from this word if they can 
execute. If so, they increment the count and, when finished, 
decrement the count. 
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PFLOAD needs to interlock a whole device so that i t i s assured 
no one else (namely PFM) is changing the device (such as catalog 
entries or track chains) as it is loading the device. 
Therefore, since PFLOAD only knows if there is activity on some 
device and not necessarily if it is the device it wants to load, 
PFLOAD sets a tot a I i nt er lock in PFNL which prevents any new 
activity on any device. Once all activity has subsided, PFLOAD 
sets the MST interlock (permanent file utility active) for the 
device it is interested in and drops the total interlock in PFNL 



Likewise, CMS sets the total interlock in order to prevent 
further activity. However, in the case of CMS, this is done 
halt all activity while it changes device configurations. 



to 



The permanent file utilities are allowed to execute in a multi- 
mainframe environment in the same manner as in a standalone 
system. To accomplish this the PFNL word (110 in CM) is kept in 
the FAT table (entry 0) (refer to section 2) in ECS. Each PFNL 
word in ECS is maintained separately buta global word is also 
used to control total permanent file activity. 

To accommodate the updating of PFNL, options are provided on the 
IAUM monitor function to do the following: secure/ re lease total 
interlock; secure/ release request for total interlock; and 
increment/decrement activity count. 



I/O QUEUE PROTECT 

Queue file protection when in MMF mode presents special problems 
when the following occur*. 

• A down machine does a level-0 deads tart. 

• MREC is run on another machine to clean up the device for 
the down mach ine . 

When a machine running with QPROTECT enabled goes down, it must 
decide what is done with the previously active queued files that 
reside on a shared device whose IQFT file is actively being used 
by another machine. 

In this case, the queued files are retained since they have the 
preserved file bit set on them; however, they are inaccessible 
until all machines do a level deadstart. 

When a machine not running with QPROTECT enabled has dequeued 

file entries in the IQFT of a shared device and goes down, it 

must decide how to delete IQFT entries once the local tracks for 

such files are dropped. 

Here, dequeueing is not allowed if the queued file is not 
preserved and the device is a shared device. In this case a 
dayfile message is issued indicating that the queued files were 
ignored on the shared device. 
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CPUMTR CONSIDERATIONS 

A significant amount of code is required in CPUMTR to support a 
mult imai nf rame environment which is not needed by sites not 
utilizing this feature. Since CPUMTR resides in central memory, 
it is desirable to provide a mechanism whereby code associated 
with a particular feature (in this case mu It imainf rame) may be 
optionally loaded or discarded at system deadstart time. 

SEGMENTATION 




A CPU program, CPUMLD, loads the desired CPUMTR blocks. CPUMLD 
is a simple relocating loader which reads in and loads the 
segments required to utilize any optional feature selected 
during the prior deadstart process. This covers the case of 
wanting one set of code for environment A and another set for 
environment B. STL loads CPUMLD, and CPUMLD issues requests to 
STL to read in CPUMTR from the deadstart tape. 

ECS INTERLOCKS 

When operating in MMF mode most of the device related interlocks 
must be maintained in ECS in order to access them from all 

machines. To provide control for the access of these 
interlocks, another level of interlocks has been defined in the 
ECS flag register which must first be secured before accessing 
and changing the respective ECS areas. The following ECS flag 
register interlocks have been defined for this purpose. 

TRTI Interlock 

Secured whenever updating an MST or TRT in ECS. Updating 
includes attempts to secure interlocks maintained in the MST 
itself. Because of the high frequency usage of this interlock, 
the machine mask identifying who has the interlock is kept in the 
flag register also instead of in ECS as for the other flag 
register interlocks. This reduces the number of ECS accesses 
and therefore reduces the interruptions of data transfers. 

PRSI Interlock 

Secured by a machine when assigning or updating the machine ID 
words in the environment table. This occurs on all levels of 
deadstart during CPUMTR PRESET when a machine is being recovered 
or assigned. 
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BTRI Interlock 



Secured by a machine which wants to perform a block transfer 
via the ECS storage move area (sector 17B of the label track). 



MRUI Interlock 



Secured by the machine recovery utility (MREC/1MR) before 
attempting to recover ECS tables, interlocks and shared devices 
from a downed machine. This is to prevent another machine 
recovery utility from doing the same thing simultaneously. 



CIRI Interlock 

Secured by CPUMTR when cleaning up the flag register interlocks 
and device interlocks for a downed machine as soon as it senses 
that it is down. This is to prevent another CPUMTR from 
attempting the same thing simultaneously. 

DATI Interlock 

Secured by any program that is searching, adding entries to, or 
deleting entries from the FAT or the DAT. Also secured by any 
program that wants to change an existing DAT entry or update the 
DAET/FAET words in the environment table. 

FATI/PFNI Interlocks 

Secured by CPUMTR or MREC to update PFNL words or to update 
existing fast attach entries. 

IFRI Interlock 

Secured by CPUMTR when entering an inter-machine function 
request . 

COMI Interlock 

Set by CPUMTR when communication processing is requested of 

other machines. 

CMR INTERLOCK TABLES 

There are two types of CMR tables that reside in ECS that ha^ 
interlocks associated with them. These are the MSTs and the PFNL 
(refer to section 2) which require the following interface. 

PFNL Table 

All PFNL updating for a machine must be performed via the IAUM 
function. This includes: request / release total interlock, 
request/release request for total interlock, i ncrement /decrement 
activity count, and family count. CPUMTR must secure PFNI 
before performing the update. 
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Global area words TDGL, ACGL, SDGL and local area word STLL are 
only updated by CPUMTR. The remaining global areas are only 
updated by CMS and IMS. (CMS and IMS use ECSM to update these 
areas in ECS.) Initial set-up is performed by CMS/RMS which has 
unavailable set for interlock; the PFNL total interlock is 
secured when recovering a new device and when removing a device. 

Local areas (currently only DULL) are updated by obtaining the 
local utility interlock (in STLL). This interlock is secured and 
released in place of the former device interlock (COMfSDI and 
COMPCDI) for those programs that still require it. 



Local areas are written to ECS without any interlocks, 
areas written to ECS require an interlock. 



Global 



TRTI (flag register), is used by CPUMTR when interlocking the 
device. A device must be interlocked when writing the TRT and 
words TDGL, ACGL and SDGL. 

IMS has initialize set which acts as an interlock for the rest of 
the global area. CMS/RMS have unavailable set for initial setup. 

All updates necessary in CPUMTR's words (TDGL, SDGL, ACGL, STLL) 
must be requested via the STBM function. Non-CPUMTR words must 
be updated in ECS (if shared device) by the respective PP program 
via ECSM. 



INTERLOCK REJECT HANDLING 

When CPUMTR attempts to secure one of the various interlocks it 
may find that it is interlocked by another machine. There are 
three things it can do with the function. 

• Retry the request. 

• Return an indication to the PP that the interlock could 
not be secured. PP resident would sense this situation 
and reissue the function following a delay. 



• Return an indication to the PP that the interlock 

could not be secured. The PP program itself would decide 

what to do next. 

Following steps describe how rejects of various interlocks are 
hand led . 

1. Any reject on ECSM/SFRS (set flag register bit) is 
communicated back to the PP program. 

2. If CPUMTR cannot secure BTRI, it performs a regular 
storage move instead of through ECS. 

3. For monitor functions which require securing of a flag 
register interlock (TRTI, FATI/PFNI) to complete, 
monitor attempts to secure the interlock n times. If 
still unsuccessful, the monitor function is requeued to 
PPR so that PPR can reissue it after a delay. 
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The flag register interlock may be secured; however, the 
next Level of interlock (device interlock) may not be 
obtainable. The associated flag register interlock is 
released and the unsuccessful attempt is requeued for 
retry by PPR. 

Likewise, the PFNL interlock may not be obtainable- 
Rejects of this type must be processed on an individual 
basis. In most cases it is not advantageous to have PPR 
continually retry the function. Whenever possible, the 
function should be rejected back to the PP program so 
that it can go on recall or perform other processing 
that minimizes resource monopolization. 

Since most function requests continuously attempt to secure the 
desired interlock and not proceed until they have it, if a 
machine goes down and has various interlocks, it is important 
that those interlocks be cleared as quickly as possible to allow 
the function requests to complete. To accomplish this, as soon 
as CPUMTR detects that a machine has been down for four 
seconds, a routine (in CPUMTR) is executed to clear interlocks 
the downed machine may have in the following areas. 



• Flag register 

• Track interlocks 

• Device interlock 



(MST/TRT) 



All other interlocks and requests for same must wait until the 
operator i ni t i ates MREC . When interlocks of the latter type are 

encountered, a reject is returned to the PP program so that it 
can process i t . 

INTER-MAINFRAME FUNCTION REQUESTS 

In the processing of ECS parity errors, it is sometimes necessary 
to have an ECS table restored by another machine. This is 
accomplished by an inter-mainframe function request (IFR). There 
are two ways it initiates an IFR. First, in the case of ECS 
parity error processing, the IFR is issued internally to CPUMTR. 
The second method is for PP programs to issue an IAUM function 
that enters the function request and its communication 
information in an ECS communication area. Following is the format 
of the IFR. 
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IFR Format for fast attach track parity error processing. 
59 



IFR + O 



+ 1 



request header 



FAT index 



IFR Format for device parity error processing 



59 



IFR + O 



+ 1 



+ 2 



+ 3 



SDGL for machine 1 (if machine is active) 



SDGL for machine 2 (if machine is active) 



SDGL for machine 3 (if machine is active) 



SDGL for machine 4 (if machine is active) 



C omm 

stru 

tell 

CPUM 

regi 

atte 

and 

the 

for 

desc 

for 

Leve 

pa ra 



umca 
cture 
s whe 
TR ch 
ster. 
mpt s 
read 
secon 
each 
ri bi n 
the p 
I in 
met er 



t i on 
. The 
n the 
ecks 
If 
to in 
the f 
d Lev 
ma i nf 
g wh i 
a rt i c 
the s 
s to 



i s a 
fi r 
re i 
this 
the 
terl 
unct 
el i 
rame 
ch c 
u La r 
t rue 
be p 



c com 
st L 
s at 

bit 
comm 
ock 
i on 
n th 
E 
ommu 

mac 
t ure 
roce 



p L i sh 

eve L 

Leas 

once 

un i ca 

commu 

reque 

e com 

ach m 

ni cat 

h i ne . 

It 

ssed. 



ed wit 
is the 
t one 

every 
t i on b 
n i cat i 
st wo r 
m u n i c a 
a ch i ne 
ion a r 
The 

conta 



h a 

f La 
func 

sec 
it C 
on p 
ds. 
t i on 

req 
eas 
comm 
ins 



three 
g reg 
t ion 
ond w 
COMI) 
roces 
One 
stru 
uest 
conta 
un i ca 
the f 



- Leve L i 
i ster bi 
request 
hen stat 
is set , 
sing (IF 
machine 
cture, i 
word is 
in f unct 
t i on are 
unct i on 



nf or ma t i on 
t COMI which 
present, 
using the flag 

then CPUMTR 
RI flag bit) 
request word, 
s allocated 
a bit table 
ion requests 
a is the last 
number and 



The following flag register bits are used for inter-mainframe 
function processing. 



Bit 

COMI 

IFRI 



Desc ri pt ion 

Set when at least one function request is present 

Interlocks the updating of the machine request 
words and the communication areas. 



The MMF environment table contains four machine request words 
(one for each mainframe). These describe which communication 
areas contain function requests for their associated machines 
Its format is as follows. 
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59 



machine 1 requests 



machine 2 requests 



machine 3 requests 



machine 4 requests 



duplication of above four words 



Machine request word 



Bit 

47 

46 

45 

44 

43 

4 2 

41 

40 

39 

23 

22 

21 

20 

19 

18 

17 

16 

15 



Description 



Communication area 
Communication area 
Communication area 
Communication area 
Communication area 
Communication area 
Communication area 
Communication area 
Communication area 
Communication area 
Communication area 
Communication area 
Communication area 
Communication area 
Communication area 
Communication area 
Communication area 
Communication area 





1 

2 

3 

4 

5 

6 

7 

8 



1 

2 

3 

4 

5 

6 

7 

8 



f lawed 
f Lawed 
f Lawed 
f Lawed 
f Lawed 
f Lawed 
f Lawed 
f Lawed 
f Lawed 



communication area, a read is 




request. 
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PARITY ERROR PROCESSING 

The purpose of ECS parity error processing is to report and 
recover the following types of errors. 

• Transient errors in a block read or write which can be 
recovered by retrying the instruction. 

• Solid errors in a block read or write which can be 
recovered by single word transfers of the block. 

• Solid errors on a read which can be corrected by 
rewriting the correct data. This type of error is 
recovered for MSTs/TRTs and fast attach track entries. 

When an ECS error (half exit) occurs, the following steps are 
pe rf ormed . 

1. Increment the ECS error count in word DSLL of the MST 
for ECS. 

2. Retry the block read/write one time to check for the 
first error type. If the error can be corre c t e d by 
this method, reporting is done and normal processing 
cont i nues . 

3. Retry the transfer with single word read/writes. If 
the operation is a read, the data read with the single 
word transfer is compared with the data read on the 
block read. This allows the detecting of the good and 
bad data for the second error type. 

4. If the error is recovered by single word transfers, it 
is reported and normal processing continues., 

5. If the error is unrecovered it is reported and the 
appropriate error action taken. 

NOTE 

A single retry is the optimum number for 
either the single or block transfers. 
If failures are still encountered on the 
single retry, it is highly doubtful that 
the integrity of the data can be trusted 
even if future recovery attempts were 
successful. 

A recovered error is reported and normal processing continues. 
Write errors are retried and reported where possible. If an 
unrecovered write error occurs, the following message is 
displayed at the system control point and central monitor will be 
s topped . 

HUNG - ECS ERROR 

The following is a list of error actions for unrecoverable 
errors. 
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MRT parity error processing. 

• The master copy of an MRT resides in CMR following 
the TRT. 

• If an error occurs in writing the MRT words to ECS, 
the error is reported and ignored. 

• If an error occurs in reading the MRT (this is done 
when clearing track interlocks for a down machine), 
the error is reported and no clearing of track 
interlocks is done for that device. 

ECS clock error processing. 

o If an error occurs while writing the ECS clock for 
this machine or while reading all clocks to status 
machines, the error is reported and the statusing of 
the clocks is not done. 

Flag register interlock words. 

• When setting or clearing a flag register bit, a word 
is written indicating which machine has the flag 
register bit interlocked. 

• If an error occurs while writing one of these words, 
the error is reported. 

• If an error occurs while reading these words, (during 
down machine processing to clear flag register 
interlocks), the error is reported and down machine 
processing is aborted. 

MST errors in down machine processing. 

• The first three words of the MST are read to check if 
the device interlock is set by a down machine. 

• If an error occurs while reading these words, down 
machine processing is aborted. 

ECSM errors. 

• If an error occurs in any ECS subfunction, the error 
is reported and the error address returned to the 
calling program. 

Machine request word errors. 

• The machine request words are written in duplicate to 

ECS 

• If an error occurs while reading the first four 
request words, an attempt is made to read the 
dup li cate wo rds . 

• If these cannot be read, the IFRI interlock is left 
set and processing is terminated. The message SYSTEM 
ECS TABLE ERROR, is displayed at the system control 
point. 
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7. Device error parity error processing. 

• When an MST/TRT read error occurs, an IFR (refer to 
figure 21-2) is initiated to request the rewriting of 
the ECS tables for this device. This request is 
processed by all active machines including the 
machine initiating the request. The TRTI flag 
register interlock is left set until processing of 
the IFR is comp lete. 

• The processing of this request involves the 
following steps. First, search for the specified 
device by comparing ECS addresses of MST/TRT. If the 
device is not found, processing is cleared for this 
machine. If the device is found, the MRT is written 
to ECS. Next, set the device update count in this 
machine's slot in the IFR. Then check to see if this 
machine has the maximum device update count. If this 
machine does not have the maximum update count, 
processing is complete (but not cleared) for this 
machine. If this machine has the maximum update 
count, the ECS and CM copies of the MST/TRT are 
compared and all errors . reported. Next, the MST/TRT 
is then written to ECS, a checkpoint request is set 
for the device, processing is cleared for all 
machines, and the TRTI flag fit is cleared. 

8. Fast attach track parity error processing. 

When an ECS read error occurs while reading a fast 

attach track entry, an IFR (refer to figure 21-2) is 

initiated to request all active machines to process this 
FAT entry. 

In processing the IFR the following steps are done. 
First, the FAT entry is read. Next, search for the FAT 
entry in the FNT. Entry equals PFNL is a I way s present . 
If it is not found, set zero word for this machine's 
entry. If it is found, reconstruct the entry from the 
FST. Then compare the computed entry with the entry read 
from the FAT. If there is a difference, report the error 
and write the correct word to ECS. Finally, recompute 
total counts word, write to ECS and clear processing for 
this machine. 

REPORTING OF ECS ERRORS 

For each word that is in error, the following information must 
be passed to a PP program for reporting. 



Read/write indication 

CM address of transfer 

ECS address of transfer 

Word count of transfer 

ECS error count (DSIL word of 

Good/bad data present flag. 

Bad data 

Good data 

Retry count 



ECS MST) 
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There could be as many words in error as the size of a TRT. 
This represents a Large amount of data to be stored for 
reporting. To avoid having a CM buffer for storing this data, a 
PP program 1MC is assigned when reporting ECS parity errors. 
This program buffers the three-word blocks of error information 
into PP memory. When all the data for this error is passed, 2MC 
is called in to process the data. 1MC must be assigned and 
loaded while CPUMTR is active (possibly in monitor mode). This 
means that the library search and load of 1MC must be done 
without any monitor functions. If no PP is available, the 
reporting is not done. 

The format of the error log message is as follows. 

ECxxxx,R/Wyy,R/U/S,zzzzzzz,Cxxxxxx,Wxxxxxx. 

ECxxxx,R/Wyy,R/U,Gxxxxxxxxxxxxxxxxxxxx. 

ECxxxx,R/Wyy,R/U,Bxxxxxxxxxxxxxxxxxxxx. 



EC 

X XXX 



R/W 

YY 

R/U/S 



Indicates ECS error through CPU port. 

ECS error incident number (word DSLL of ECS MST) 

xxxx=0 indicates reporting error from another 

mach i ne . 

Read or write error indication. 

Retry count. 

R = recovered error. 

U = unrecovered error. 

S = error recovered by single word transfers. 



zz . . 

Cxx . 
Wxx . 
Bxx . 
Gxx . 



. z 
. x 
. x 
. x 
. x 



ECS address of transfer 
CM address of transfer. 
Word count of transfer. 
Bad data. 
Good data. 



OPERATOR INTERFACE - DSD 

DSD and DIS displays are available (similar to CM displays) to 
display the contents of ECS. Console commands also allow the 
operator to enter changes in ECS. 

The contents of the flag register are interrogated every second 
by CPUMTR and stored in central memory location EFRL. DSD 
displays the contents of EFRL on the ECS displays. 



Two DSD commands manipulate the flag register bits. 
SFRn. and CFRn. to set flag register and clear flag 
where n is the bit number to process. 



These are 
regi ster 



MACHINE RECOVERY - MREC/1MR 

MREC is a CPU program called by the operator which interfaces 
with the operator via a K display. Its main function is to 
clear interlocks held by an interrupted machine which have not 
been cleared by CPUMTR. It also recovers mass storage space on 
a shared device that is currently not accessible because one of 
the other machines in the complex has interrupted. 
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When initiated, MREC displays the status of the devices this 
machine is sharing and the other machines with which it is 
sharing them. The operator must indicate the MID of the machine 
for which the recovery is being attempted as well as the devices 
to recover. MREC then calls PP program 1MR, which performs the* 
following steps to recover the interrupted machines shared 
devi ces . 

• Clears any hardware unit reservations that may be 
preventing other machines from accessing the device. 

• Clears device accessed bit for interrupted machine in the 
DAT to prevent non-level-Q recovery. 

• Clears interlocks and user counts in system sectors for 
the down machine. 

• Processes MRT to release local file space held by the 
downed machine. 

It may be necessary to run the machine recovery utility on all 
machines still up. This is dependent upon which machines were 
sharing devices with the down machine. 

When 1MR attempts to access a device, it may determine that it 
is unable to because the other machine has left its channel 
access reserved or the unit reserved. 

In the case of reserved channel access, this status is relayed 
to the operator via the K display. The deadstart button must be 
pushed on the interrupted machine which will issue a master 
clear on the channel which in turn clears the reserve. (This 
handles any reservation situatios for the 841.) 

If it is a case of unit reserved, 1MR determines if another 
machine can access the unit from the other side and notifies via 
the K display what machine that is. If so, it leaves it up to 
that machine to initiate its recovery utility (MREC) in order to 
clear the reserve. Otherwise, this machine issues the grenade 
function (7054/0011) which clears all unit reserves on the other 
side. 

In the event there are three machines that can access a given 
unit and one of the machines is interrupted and leaves that unit 
reserved, it is not always possible for the other machines to 
determine if they can clear the reserve without affecting each 
other. If this situation exists, each machine informs the 
operator. The only case of concern is when both machines are on 
the opposite side of the unit (connected to a different 
controller) from the interrupted machine, in which case either 
machine could clear the reserve. Therefore, the operator must 
specifically direct the utility on one of the machines to clear 
the reserve. 

If it is found that the interrupted machine had a checkpoint 
request pending, that request is transferred to this machine in 
order to have it satisfied. The ECS copy of the MST/TRT is 
checkpointed to the device. 
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When the machine recovery utility is required to perform 
functions that are otherwise illegal for ^l 8 "!S5 'J! recover^ 
drop tracks reserved to another machine), in order to recover 
that machine's mass storage, a special bit is required to be set 
on the pertinent monitor functions which indicates that this 
function should be allowed to execute whereas it would otherwise 
be i I lega I - 
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CYBER 170 RAM 



22 



This section contains descriptions of several features of NOS 
that are specifically concerned with reliability, availability, 
and maintainability (RAM). 

The following subjects are detailed. 



List hardware registers in deadstart dump 

S/C register error logging 

CYBER 170 power failure and environment bits 

Unhangable I/O channel code 

Output channel parity error detect i on/ loggi ng 

BATCHIO unit record equipment 



LIST HARDWARE REGISTERS IN DEADSTART DUMP 

By selecting the express deadstart dump (E) option, the user 
has access to the S/C register contents of a CYBER 170, and 
also the contents of the hardware registers at deadstart time, 
both of which may contain valuable information as to the source 
of a problem. This is done in the deadstart dump routine EDD. 



ROUTINE EDD 

EDD has two subroutines, DSC and 
reads up and writes to tape the 
a CYBER 170. A four-word header 
by one record for the contents o 
register record has a one-word h 
the register. DCP exchanges a p 
hardware register contents at de 
header is written to the tape fo 
hardware register contents of ea 
register record has a one-word h 
number. The header and records 
dump tape. 



DCP, to accomplish this. DSC 
contents of the S/C registers of 

is written to the tape followed 
f each S/C register. Each S/C 
eader identifying the channel of 
ackage in CM to obtain the CPU 
adstart time. A four-word 
llowed by one record for the 
ch existing CPU. Each hardware 
eader identifying the CPU 
follow the CM dump record on the 



60454300 B 



22-1 



DSDI has two options, SC and XP, which utilize these records. 
The SC option checks for the S/C register Label and, if there, 
prints out the contents of the registers. SC also prints out an 
informative message if the I deadstart option is chosen. The XP 
option prints out the CPU hardware register contents. 



The 

dump 

ins 

(fig 

regi 

word 

chec 

act i 

t ape 

S/C 

DSC 

ex i s 

regi 



S/C r 
, or 
ubrou 
ure 2 
ster 
s to 
ks if 
ve. 
. If 
regi s 
check 
t, re 
ster 



egi ster 
first o 
tine DS 
2-1) fo 
(figure 
be comp 

the ma 
If not 

a CYBE 
ter and 
s f or 2 
ads up 
content 



s are written to the dump tape prior to the PP 
n the tape (refer to figure 2 2-1). This is done 
C. The dump includes a four-word header label 
llowed by a record for each existing S/C 

22-2). Each record must be a multiple of 4 CM 
atible with any type of tape unit. DSC first 
chine is a CYBER 170 by checking for channel 16 
active, DSC exits without writing to the dump 
R 170, DSC reads the contents of the channel 16 

writes the contents to the dump tape. Next, 
PPs by checking channel 20 active, and if they 
and writes to the tape the channel 36 S/C 
s . 



59 







SCR 



express nn (nn is dump identifier) 



Figure 22-1. Dump Tape Header Label 
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59 


47 


35 


23 










SC 


channel 





register bits 203 through 144 


register bits 143 through 84 


register bits 83 through 24 


register bits 23 through 





unused 


unused 


unused 



Figure 22-2. Dump Tape Record Format 
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The PP dump includes a four-word header Label (figure 22-3) 
followed by several records of PP dumps formatted as in figure 
22-4. 



59 



PP 



express nn (nn is dump identifier) 



Figure 22-3. PP Dump Header Label 



59 


47 






35 


23 







word 


PP 


PP number 


words 3 and 4 


words 5 through 11 










• 









■* 


• 


words 7772 through 7776 


word 7777 






Figure 22-4. PP Dump Format 



The CPU hardware register contents are written to the dump tape 
following the CM dump record (figures 22-5, 22-6, and 22-7). 
This is done in subroutine DCP. The dump includes a four-word 
header label followed by a record containing the register 
contents of CPU and a second record for the register contents 
of CPU 1, if it exists. An exchange package is exchanged in the 
CPU to obtain the contents of the registers at deadstart time. 
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59 



11 



CM 



size/1000 



express nn (nn is dump identifier) 



Figure 22-5. CM Dump Header Label 



59 



FPP 



express nn (nn is dump identifier) 



Figure 22-6. FLPP Dump Header Label 
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59 







CPR 



express nn (nn is dump identifier) 



Figure 22-7. CPU Hardware Register Contents 



Next, an ECS dump is provided, including a four-word header 
Label (figure 22-8) and one record containing the dump of ECS 



59 



29 







ECS 



flag register 



size/1000 



express nn (nn is dump identifier) 



•Not used on CYBER 170 Model 176 



Figure 22-8. ECS Header Label 
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a 

rat 



59 



BC 



express nn (nn is dump identifier) 



Figure 22-9. ControLware Header Label 



59 



47 



35 



23 



byte 



byte 
I7776B 



CH 



channel 
number 



bytes 3 and 4 



bytes 5 through 1 1 B 



bytes I777IB through I7775B 



byte 
I7777B 



J 



Figure 22-10. ControLware Dump Format 
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DSDI 

SC causes the S/C register contents to be printed, and XP prints 
the CPU hardware register contents. 

yhen SC is specified, the dump tape Label is checked for SCR. If 
the Label does not contain SCR, an informative message is issued 
by DSDI. If the label contains SCR, a page header is printed 
and the label checked for the I option flag. 

The next record is checked for a header word, aborting with an 
error message if it does not exist. If it does exist, the 
channel 16 S/C register contents is printed in octal format 
(figure 22-11). Again, the next record is checked for a header 
word. If one exists, the channel 36 S/C register contents is 
p r i nt ed . 

When XP. is specified, the dump tape is searched for the label 
containing CPR. If not found, an informative message is issued. 
If found, the record following the label is checked for a 
header word, aborting with an error message if it does not 
exist. If it does, the record is read, and the hardware 
register contents printed in the format shown in figure 22-11. 
Again, the next record is checked for a header word. If one 
exists, the CPU 1 hardware register contents are printed. 

Refer to the NOS System Maintenance Reference Manual for the 
format of the DSDI call. 
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S/C Register 

BITS 59 - 0000 0000 0000 0060 0001 

BITS 119 - 60 0000 0000 0000 0000 0000 

BITS 179 - 120 0000 0000 0000 0000 0000 

BITS 203 - 180 0000 0000 



Hardware Registers 

P A0 

RA 317700 A1 

FL 50000 A2 

EM* 7007 A3 

RAX A4 

FLX A5 

MA 2400 A6 
EEA** xxxxx A7 

XO 0000 0000 0000 

X1 0000 0000 0000 

X2 0000 0000 0000 

X3 0000 0000 0000 

X4 0000 0000 0000 

X5 0000 0000 0000 

X6 0000 0000 0000 

X7 0000 0000 0000 



BO 





B1 





B2 





B3 





B4 





B5 





B6 





B7 





0000 0000 




0000 0000 




0000 0000 




0000 0000 




0000 0000 




0000 0000 




0000 0000 




0000 0000 





Figure 22-11. Dump Formats 



* PSD for the CYBER 170 Model 176. 
** CYBER 170 Model 176 only. 
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S/C REGISTER ERROR LOGGING 

Routine 1MB / called when an SCR error bit is detected set by 
MTR, first checks the S/C register for fatal errors and then for 
bits 36 and/or 37 set. If either is set, the procedure described 
in the next subsections, CYBER 170 Fatal Mainframe Errors or 
CYBER 170 Power Failure and Environmental Bits, are followed. 

If neither of these conditions are present, 1MB S/C register 
processing will, for each available S/C register, clear 
appropriate error bits, issue an error message to the error log, 
and place the contents of the S/C registers in an appropriate 
4-word CM register buffer (S16L and S36L CM buffers). Routine 
1MB Looks at the bit table TOBR corresponding to the error bits 
checked by the test/error function (bits 0-39 of each S/C 
register). If a bit is set in the bit table, and also set in 
the S/C register, 1MB will inclusively OR the bit into the CM 
S/C register buffer. 

For single error bit SECDED status, 1MB issues error log 
messages when a threshold value is reached. If a error is 
detected and the threshold valuje has not been reached before a 
time interval expires (time = approximately 1 hour), a message 
is sent to the error log stating the number of single bit errors 
that have occurred since the last single bit error entry in the 
error log. All detected double bit SECDED errors are logged. 

When 1MB is finished, it clears bit 59 in CM location SCRL, set 
by MTR, to reenable S/C register error logging. 
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CYBER 170 FATAL MAINFRAME ERRORS 

This feature minimizes the damage to the system and to user 
jobs and improves system recoverabi Li ty where possible, upon 
the occurrence of fatal errors caused by problems in the CYBER 
170 hardware. The term fatal errors refers to errors that are 
virtually certain to eventually cause uncontrolled system 
crashes unless they are detected early and guarded against. For 
purposes of discussion, fatal errors are divided into two groups 
as listed below, along with the status bits set in the SCR upon 
their occurrence. 



Group 1 
CSU address parity error 
CSU faults 
PP stop on CM read error 



Status Bits 

1 and 2 

8 and 9 

0, 3, 182, 183, 
14-23 



PP stop on PP parity error 



14-23 



Group 1 
Doub le SECDED error 
CMC input parity error 



Status Bits 
3 and 183 
5, 54, 55 and 139 



GROUP I ERRORS 

Group I errors are normally detectable only because of being 
recorded in the SCR and only after an indeterminate amount of 
processing has continued. In addition, the errors are not 
usually confined to one job's field length, making segregation 
of the affected area less easy. A level deadstart is normally 
required after the hardware is corrected. Therefore, improving 
recoverabi lity will not likely be beneficial but taking 
immediate steps to minimize the effects of the error is 
essential. The following sequence is performed. 

1. 1CK is called to attempt a checkpoint of mass storage. 

2. The system is placed in step mode. 

3. The following message is displayed at the system 
control point. 

FATAL MAINFRAME ERROR. 

4. The fatal error bits set in the SCR are not cleared and 
the operator command UNSTEP is not allowed so that a 
deadstart is required. 
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5. SCR analyzes fatal error bits on deadstart and displays 
a more informative error message than that in step 2. 

6. SCR allows deadstart to proceed only after all fatal 
error bits have been cleared. 



GROUP II ERRORS 

Group II errors cause an error exit upon occurrence, permitting 
CPUMTR to immediately take steps to localize the effects of the 
error. After this is done, efforts can be made to optimize 
recovery capabilities. The following actions are taken. 

1. CPUMTR sets the PEET error flag for jobs getting a 
mode 20 or 40 error flag. 

2. 1AJ checks the SCR for jobs with PEET error flag. If 
a mode 20 or 40 has occurred, the job remains at the 
control point while the rest of he system is 
checkpointed. If the job has faked a mode 20 or 40 
error it is aborted with no exit processing and no 
dump . 

3. MTR when moving a control point checks for the PEET 
error flag and if set validates through the SCR that a 
mode 20 or 40 error has occurred. If so, the mode 
request is rejected and 1MB is called. 

4. The following message is displayed at the system 
cont roL point. 

FATAL MAINFRAME ERROR. 

5. 1MB initiates a system checkpoint. 

6. The contents of the SCR is entered into the error log. 

7. After the system checkpoint is complete, the system is 
placed in step mode. 

8. The fatal error bits set in the SCR are not cleared 
and the operator command UNSTEP is not allowed so that 
a deadstart is required. 

9. SCR analyzes fatal error bits on deadstart and 
displays a more informative error message than that in 
step 3. 

10. SCR allows deadstart to proceed only after all fatal 
error bits have been cleared. 

NOTE 

If CPUMTR or IAF/TELEX itself hardware error exits, 
the procedure described for Group I errors is 
followed. 
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If contrary to recommended procedure, the 
installation is operating in parity mode when a 
CM parity error is encountered, only steps land 2 
of the Group II procedure are performed. This is 
because the remaining steps are dependent on the 
SCR error bits for initiation and, in parity 
mode, there is no indication provided for CM 
parity error in the SCR, nor even any indication 
that the system is in parity mode. 

CYBER 170 POWER FAILURE AND ENVIRONMENTAL BITS 

Status and control register (SCR) bit 36 indicates main power 
failure. On the CYBER 70, bit zero of the interlock register 
CILR) serves a similar function. SCR bit 37 indicates an 
environmental failure. One of the two sequences following is 
initiated upon deletion of the setting of either or both bits: 



If (CYBER 170 only) SCR bit 37 (environmental) is set, but 
bit 36, the following steps occur. 



not 



1 . 



2. 



3. 
4. 



A message is displayed at the system control point 
indicating bit 36/37 conditions. The SCR contents are 
logged in the error log. 

A system checkpoint is performed. All programs are 
automatically idled by this action. (During steps 1 and 
2, the SCR is continuously monitored and the displayed 
updated. If mains failure becomes set, the second 
sequence is initiated immediately). 

The system is placed in step mode. 

The SCR continues to be monitored and the display 
updated. After (and not until) bit 37 clears, the 
operator may enter an UNSTEP command and normal 
processing may be restarted using existing facilities. 
After the UNSTEP, the time at which bit 37 last went 
clear is entered into the error log. 



ILR bit on a 



If SCR bit 36 (main failure) on a CYBER 170 or 
CYBER 70 is set, then the following steps occur. 

1. A message is displayed at the system control point 
indicating SCR bit 36/37 or ILR bit conditions. 

2. The system is placed in step mode. 

3 The SCR or ILR is monitored and the display updated. 
After (and not until) SCR bits 36 and 37 or IRL bit 
are cleared, the operator may enter an UNSTEP command 
and normal processing may be resumed using existing 
facilities. After the UNSTEP, the time and contents of 
the SCR when bit 36 was set and the time and contents 
of the SCR when bit 36 last cleared are entered into 
the error log. The system is placed in step mode. 
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SYSTEM FLOW 

MTR checks 
to process 
running on 



the SCR each time through its main Loop and calls 1MB 
any errors detected. MTR checks the ILR bit if 
a CYBER 70. 



SCR Bit 37 Only Set 

Upon detecting bit 37 and not bit 36 set (or not ILR bit 0), 1MB 
enters the time and the contents of the SCR in the error log. 
In addition, a message is placed in buffer MS2W of the system 
control point area for display by DSD on the B display. From 
this time until 1MB drops, the SCR (or ILR) is continually 
monitored. If SCR bit 36 (or ILR bit 0) becomes set, 1MB 
immediately starts the procedure described in the next 
subsection. 
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The MTR STEP function processor sets bit 1 of INWL and the 
UNSTEP processor clears it. DSD will not process an UNSTEP 
function if bit 57 of word SCRL is set. 



SCR Bit 36 Or ILR Bit Set 

When 1MB detects SCR bit 36 set (or ILR bit 0) indicating main 
power failure, processing is similar to the description in the 
previous subsection, except 1CK is not called, and no error 
logging is performed prior to setting SCRL bit 57. STEP mode is 
set by MTR immediately and 1MB internally records the time of 
detection of bit 36 set and the contents of the SCR. Upon the 
operator entering UNSTEP after bit 36 has cleared, both setting 
of the bit and clearing of the bit messages are sent to the 
error log . 
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UNHANGABLE I/O CHANNEL CODE 



It is necessary to establish that regardless of the software 
technique employed by the drivers to support unhangable I/O 
channel code, the end result is something less than complete 
protection against PPs hanging as a result of I/O channel 
failures- This results because certain hardware failures cannot 
be compensated for by any form of unhangable channel protect 
code . 



Past experience indicates that hardware problems 
I/O channel hangs have been most frequently asso 
remote (as opposed to the display controller) pe 
controllers; more specifically, magnetic tape an 
storage controllers. I/O channel hang problems 
to the complexity of the hardware required to po 
data, and, to read/write data on the peripheral 
Response timing between a magnetic tape drive an 
controller is more critical than similar respons 
a display console and its controller. This resul 
unpredictable variations in timing as a conseque 
mechanical motion directly associated with the r 
data. An electronic peripheral device (that is, 
controller) is inherently more reliable in I/O c 
communication since the PP-to-cont rol ler interac 
dependent entirely on electronic circuit respons 
the combination mechanical/electronic responses 
other peripherals. 



resu It i ng in 
ci ated wi th 
ri phera I 
d rotating mass 
di rect ly re late 
s i t i on to the 
device, 
d associ ated 
e timing between 
ts from the 
nee of 
ead/wri te of 

di sp lay 
hannel 
t i on is 

es as opposed to 
associ ated with 



DRIVERS 

In general, 
received in 
i nstances, 
t ransmi ts t 
and, i f act 
channel to 
in the erro 
bit 5 set a 
error condi 
PP/ cont roll 
being check 
I/O perform 



all drivers verify that an inactive signal was 
response to a function command. This will, in most 
consist of an issue function subroutine that 
he function code, checks for inactive on channel, 
ive, initiates a time-out loop while waiting for the 
go inactive. A time-out results in logging the error 
r log file, deactivating the channel using DCN with 
nd, if applicable, a retry after detection of an 
tion. This technique is implemented provided the 
er interface timing for the function command sequence 
ed allows the increased overhead without degrading 
ance . 



Imp lemen 
areas of 
speci fie 
Another 
requi red 
potent i a 
examp le, 
concept, 
probabi I 
overlays 
support 



tation of additional unhangable I/O channel in other 
the drivers is dependent upon identification of 
problem areas on the basis of current experience. 

consideration is the availability of space for the code 
in the driver to support this concept versus the 

I enhancement in reliability of the system. As an 
if additional overlays must be created to support this 
the increased overhead in time and the increased 

ity of encountering an error because of loading more 
may negate any potential enhancement to be derived in 

of the unhangable I/O channel code concept. 
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Rout ine 1 ED 

A function issue subroutine is used by, the driver. If an 
inactive signal is not received within 4 major cycles the driver 
aborts the subsystem after issuing an appropriate message to the 
error log. Bit 5 is used by all DCN instructions. Routine 1 ED 
checks for complete transfers on I/O instructions. 



both input and 
major cycles. Bit 5 
is issued upon a 



Routine 1TD 

Routine 1TD performs a function timeou.t on 
output, with an inactive required with/in 4 
is used on all DCN instructions. A message 
function timeout. Any error aborts the subsystem. 

Routines DSD, 1DL 

In the operator-initiated channel command code (DSD), the 
assembly time channel numbers are set to 40 instead of (**) 
for all IAN, OAN, ACN, DCN, FAN, and FNC instructions. This 
sets bit 5 in those instructions. Setting bit 5 in IAN, OAN, 
and DCN instructions in code for display operations and in DCN 
instructions in code for overlay loading is accomplished by 
replacing CH by CH+40 in the variable field of these 
instructions. 



OUTPUT CHANNEL PARITY ERROR DETECTION /LOGGING : 

CYBER 70 systems have no hardware capability of detecting parity 
errors between the PP and the data channel converter (6681). 

CYBER 170 systems can check for parity errors between the PP and 
the converter. If a parity error is detected by the converter, 
bit 2 and bit 11 are set in the converter's status word. Bit 11 
is unique to CYBER 170 and signifies that channel parity error 
has occurred between the PP and the converter. Bit 2 set 
signifies, an error between the converter and the equipment. 

65 x Equipment 



When the data channel converter is statused, all 12 bits of 
status are saved in order to log both bits 11 and 2. Format 
the first line of the 65x error message is 



of 



MT,Ccc-e-uu,vsnxxx,rw,eo,Sss,xxxx,yyyy . 

In the message, ss is the DCC status. The first digit is or 
depending on if bit 11 is set. The second digit is bits 2 - 
status. Bit 11 is set only if bit 2 is set, indicating 
transmission parity between the PP and DCC. If only bit 2 is 
set, parity occurred between the DCC and equipment. 



1, 
of 
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NTS Equipment 

If channel parity occurs on a function issue or parameter 
output, the general status alert bit is set and error code of 
detailed status is set to the following. 

55B Channel parity occurred when a function was 
transmitted 

54B Channel parity occurred when data or parameters were 
transmitted 



he message CHANNEL MALFUNCTION is then issued and the error 
ode appears in the detailed status indicating that channel 



Tl 

code app< — - ... ... 

parity has occurred. If channel parity errors occur while 
transmitting status functions, no status information is returned 
from the tape controller. 



If channel parity occurs on data output, the following occurs. 
Alert bit is set in general status. 
Channel parity error bit is cleared. 



Error code 54B is set in detailed status error code 
field. 

• The message STATUS ERROR is issued. 

Normal write error recovery takes place if channel parity on 
data output is detected. 



BATCHIO - UNIT RECORD EQUIPMENT 

CYBER 170 channel parity errors result in the blocking of 
response to both function and connect codes. Thus, if there is 
a transmission error between the PP and converter, the PP s 
channel is not set inactive and the PP may hang when another 
channel instruction is executed. 

For function and connect codes to the peripheral equipment, the 
question of delay length has a simple solution. Built into the 
converter is a hardware feature that, after 100 microseconds, 
deactivates the channel if there is no respone from the 
peripheral equipment. In addition, bits (reject) and 1 
(internal reject) of the converter's status word are set. 
order to use this existent hardware feature, timeout loops 
function and connect codes to the peripheral unit record 
equipment are at least 100 microseconds. Again, an inactive 
channel state occurring before the total delay causes the loop 
to terminate. All delay loops are designed to accomodate ZX 
PPs. 



In 
for 
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BATCHIO also checks bit 2 of the converter status word. If a 
parity error is found the following ERRORLOG message is issued 

eqxx,CHyy,Fzzzz REJ P0Q00, Ca aaa , Ebbbb . 

or (if there are parity errors in either of the status word 
functions) 

eqxx,CHyy,Fzzzz FUNCTION TIMEOUT. 



eq 
x x 

yy 

z zzz 

0000 
a aaa 
bbbb 



Equipment type 
Equipment number 
Channe I 
Function code 
Prog ram address 
Converter status word 
Equipment status word 
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SECURITY 



23 



This section describes various NOS features and techniques that 
are available to the site to assist in protecting system 
operations and user data from curious or malicious users. Many 
sites make local modifications to many areas of the operating 
system. As a by-product of these modifications, system and user 
data, as well as access to them, may be left in an unsecure 
condition. This section details features and techniques that 
are used to make the standard NOS system secure. 

Many of the security features of NOS are enforced through the 
job origin concept — only jobs of a given origin type can 
perform certain operations. A system origin job (SYOT) is 
usually initiated by the site analyst from the operator console 
and may perform privileged tasks that a terminal or batch user 
may not perform. It is expected that the site exercise the 
constraints necessary to limit access to the operator console 
and the privileges associated with being system origin. 

There will always be the case of the sophisticated system 
programmer who may be able to circumvent the security controls 
of any system. The security controls in the system are meant to 
protect against the batch or terminal user; the analyst who 
gains system origin access may still be able to violate security 
const rai nt s . 



SYSTEM ACCESS 



This subject covers user access to the system and the accounting 
(for subsequent billing) of the activities performed by the user. 



The 
base 
and 
can 
used 
spec 
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Sy st 
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control of user access (validation) and user accounting is 
d on two system permanent files: VALIDUs (validation file) 
PROFILa (project profile file). These files identify who 
use the system and to what projects system resources may be 

and charged. These files can be manipulated through 
ial system jobs that require system origin. The maintenance 
hese files is described for the site analyst in the NOS 
em Maintenance Reference Manual. Since these files contain 

and project numbers, the knowledge of these values should be 
ted to the user identified by these values and the site 
onnel that maintain these files. 
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The system provides for the suppression and secure entry of 
passwords and charge and project numbers. The user can use 
system mechanisms so that these values do not appear in hard 
form in his job dayfile or hard copy terminal output. Thus, 
these values can remain known only to the user and those 
responsible for maintaining them. 
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umber and password is suppressed from the 
ER statements and, at the user's 

during a terminal session Log-in. 
ressed from the dayfile for the PASSWOR 
e permanent file passwords contained in 
statement. Both types of passwords may 
entered by having the passwords read from 
rminal, the passwords are entered over a 

Charge and project numbers normally 
but may be securely entered by the reading 
ct numbers from the INPUT file Cor entered 
ence at the terminal). Whenever these 

entered, they do not appear in the 



SECONDARY USER STATEMENTS 

To protect against a user deliberately issuing USER statements 
until a valid statement is accepted by the system, the site may 
allow or disallow the processing of more than one USER statement 
in a job or terminal session by means of an installation 
parameter. This installation option may be selected through the 
use of the USERS IPRDECK entry or the SECONDARY USER CARDS DSD 
console entry. With this option enabled, the user may have more 
than one USER statement in his job. 



SECURITY COUNT 

To protect against a user who deliberately attempts to 
determine valid user numbers by attempting invalid USER 
statements when secondary USER statements are permitted or by 
submitting jobs with invalid USER statements, a security count is 
available in each user's va I i dat i on f i le entry. The security 
count is decremented each time an invalid USER statement is 
detected. When the security count reaches zero, the user will 
no longer be granted access to the system. Only the resetting of 
the security count through MODVAL will give the user access to 
the system aga in . 
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OTHER USER NUMBER PROTECTIONS 

m hor security followed in NOS is that it 
The philosophy ° f K user f ""f *'** to determine another user's 
should be impossible for a user to t ^ just Qne 

user number and password. ™ e **'e user nuinbe r validation is 

example of this. Other areas where user determin ing valid 

done also take steps to prevent the user 

user numbe rs . 

For example, if the user attests to -cess permanent ^ lousing 

an alternate user number, a f lie t f " d cona response 

if the alternate user number is not vall °; "; s der a vaU d 

does not indicate whether the file was not Pr^ent un 

lllr number or the user n^ ""1™° *" ™ f hi scanner does 

attempting to violate «^;" " " L' a . However, if 

not know whether or "« *h. u.. ^«>» r k ^*, \ e has detected a 

the file does exist, then the v ;°'"" accessor retrieved a file 

valid user number This f^*, %, ^.The °password for the 

that was public and also correctly gu- 

f i le, if one was required. 

SPECIAL USER NUMBERS 

User numbers whose user indices -e greater tj ,.n ™^,J u " X . b , p , 
(defined in common deck COMSACC) are called *P ^ USER 

Tnese user numbers e.nnot b. -^ ^cannot^e gained using 
statements. Thus, access to tne / gained to files 

these special user numbers, nor can a* * 3 ^*^ IDUs) unL ess the 
cataloged under these user numbers <»"°\" ]^ tly permitted to 
files have been made public or the user expucuiy y 
access them. 

NOS uses two special user numbers, the ^J^"^^, 
CSYSTEMX) and the library --number ^IBRARY)^ ^ ^ fUe§ 
numbers have permanent files like any u control 

rau st be cataloged under system origin « users 

statement has been entered to set the user in««. user 
may access files under these user numbers on an altern 
access basis only. 

The site may create its own special user ^f^^^ n ^ x ° a ^ve 
user index (FUI) MODVAL directive to set the user index 

AUIMX. 



23-3 



60454300 A 



USER ACCESS PERMISSIONS 

In the user validation file entry is a word containing certain 
access permissions. The setting of various bits in the AACW 
word allows the user to perform certain operations that the site 
may wish to control. Of particular note is theCSOJ (system 
origin privileges) permission. The site should exercise caution 
in selecting which users may have system origin privileges, as 
the presence of the CSOJ bit usually excuses the job from 
certain system controls if the system is running in DEBUG mode. 

The site should take care in implementing their own access 
permissions so as not to remove the controls provided by NOS. 
A complete description of the AACW access word and associated 
permission bits is provided in section 20. 



SPECIAL CONSOLE MODES 
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ed under special modes in which normally 
y be performed by certain users. If the 
G mode, then many of the controls on user 
f the user has system origin privileges 
he system is placed in UNLOCKED mode, 
mands, including the ability to alter 
ed. These special console modes should 
I system operations as their function is 
ging (DEBUG) and hardware maintenance 

protecting against accidental operator 
system operation and performance 
tor's Guide and NOS Installation Handbook 
nds and IPRDECK entries that 
onso I e modes . 



SPECIAL ENTRY POINTS 

The system performs certain operations based on encountering 
special entry points when loading programs from the system 
library. The special entry points are detailed elsewhere in this 
manual, but those entry points dealing with security techniques 
are discussed here. 
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SSJ= ENTRY POINT 

•„- ^Hicates that the program being Loaded has 
The SSJ= entry poi nt indi cates tn variety of system 
special privileges while e^ "; 1 ^- executing has the 

functions are permitted only if ne of the SSJ = entry 
special Privileges signaled by the pes $sj= pMvUeges 
point. The operations permitted oy jou* 
include the following. 

Manipulating fast attach permanent files 
increasing the job's CPU and queue priority 

. Performing input/output operations on 

execute-only files 

. Issuing RSB and SIC RA+1 calls 

• Manipulating job queues 

• Manipulating dayfiles 

_« An -i- -famiLv and pack name 
9 Ignoring current Tamiuy anu h 

specification 

• Overriding security count 

• Accessing the control statement file 

messages to the account and error log 



Issui ng 
dayf i les 



S S J = privileges 




have the capability to access 

t available to tne 
he SSJ= entry 
e permanent 



the secure system memory status 



Th« «;<;i= entry point also causes 

IS be set (refer to Hem on secure system memory ,n 

section) . 
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maintenance routine MODVAL is an example of 

accesses the validation files, VALIDUs and 
fast attach permanent files under the system 
SSJ= privileges are required so that these 
ay be accessed. All of the files created by 
with the special system ID (SSID) so that they 
tically at job completion or termination, 
e ID to zero for all files that are the output 

if they did not have an ID already specified, 
file or the source file generated during an 

since the files accessed by MODVAL are 
ecial ID, they do not remain at the control 

terminate abnormally. 



SSM= ENTRY POINT 

The SSM= entry point causes the secure system memory status to 
be set. The setting of the SSM flag prevents the dumping of any 
portion of the job's field length. Secure system memory is a 
NOS feature that is described later in this section. 



SDM= ENTRY POINT 

Programs that contain the SDM= entry point do not have their 
control statements issued to the dayfile when the program is 
loaded. This allows the processing program to suppress fields 
in the control statement that are privileged in nature. This 
technique is used by PFILES, for example, in processing 
permanent file control statements so that passwords may be 
suppressed from the control statement when it is issued to the 
dayfile. 



VAL= ENTRY POINT 

If user validation is enabled (that is, a USER statement must be 
used in every job), NOS allows only those programs containing a 
VAL= entry point to execute. The system uses this feature in 
the ACCFAM and CHARGE programs to ensure that the USER ' statement 
and CHARGE statement (if required) are properly processed. 

When the validation required bit (bit 17 in wordUIDW of the 
control point area) is set, the control statement being processed 
must be an entry point in. a. processor which has a ' V A L = entry 
point. If the processor does not have this special entry point, 
the job is aborted and the diagnostic IMPROPER VALIDATION i ssued . 
This mechanism forces the USER statement to be the first 
statement following the job statement if validation is required 
(bit 48 set in location SSTL). The processing of the USER 
statement by ACCFAM clears the validation required bit in UIDW if 
the user is not required to have a CHARGE statement (CCNR is set 
in the user's AACW word). When a required CHARGE statement has 
been processed, the validation required bit is cleared by the 
CHARGE processor. 
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SECURE SYSTEM MEMORY 

The secure system memory (SSM) feature of NOS prohibits a user 
from accessing data in central memory after the Program that 
brought the data into central memory has released storage, been 
storage moved, rolled out, completed, or aborted. Secure system 
memory involves prohibiting the dumping of privileged field 
length and clearing of memory when loading a new program or 
increasing the field length. 

This feature prevents access to data that may be left as a 
residue from other jobs or job steps that have manipulated 
privileged data or files. For example, if the LIMITS command was 
aborted and the field length dumped, the dump might expose 
validation file data to unauthorized access if the secure system 
feature was not available. 



memory 



PROHIBIT DUMPING 

The SSM bit, when set, indicates that the data in the field 




follow a job step for which the SSM status was set. 
The RA+1 calls prohibited by the SSM setting include 
CKP Checkpoint program 
Dump field length 



DMP 
DMD 

REQ 
LFM 



Dump field length with display code 
translation 

Request tape equipment assigned 

REQUEST and LABEL macro calls for tape 

assignment 



pp M Requests for removable auxiliary devices 

The following control statements may not follow job steps with 
SSM set. 



CKP 


PBC 


DMD 


RBR 


DMP 


WBR 


LBC 


RESTART 


LOC 
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The following routines have an SSM = entry point in order to 
prohibit the next job step from dumping portions of the file's 
data that may be residue in a buffer used by these utilities. 



CATALOG 



LIBEDIT 



COPYB 
COPYC 



VERIFY 
VFYLIB 



EDIT 



Other utilities that manipulate privileged system or user files 
are protected by their SSJ= entry point such as MODVAL and the 
permanent file utilities. The main reason these routines have 
the SSM= entry point is not to protect the data residue from 
being dumped, but rather to reduce system overhead as the field 
length does not have to be cleared for the next job step. 

The SSM status bit is set by the system whenever a program 
containing an SSJ= or the SSM = special entry point is loaded or 
if the program issues a SETSSM macro. The SSM status may not be 
cleared by any program containing the SSM = entry point. 
Although the SSJ= entry point causes the SSM status to be 'set, 
programs that contain the SSJ= entry point may still make RA + 1 
calls to DMP= processors. 



CLEARING MEMORY 

Central memory storage assigned in response to an RFL increase 
request for all jobs that do not have an SSM= special entry point 
is cleared when the field length is given to the job. This keeps 
any data that may be privileged from being dumped. The presence 
of the SSJ= or SSM= entry points sets the SSM status prohibiting 
field length dumping. The portion of the field length not 
loaded when loading a program without SSM = is cleared if the 
previous job step had the SSM status set. This area is the field 
length between the last RFL and the field length required to run 
the current job step. 



OTHER DATA PROTECTIONS 

The philosophy of data security followed by NOS is that it 
should be impossible for a user to access the data that may be a 
residue in his own or another's field length. The secure 
system memory feature is just one example of this. Other areas 
where data protection is done is the area of permanent file 
length errors. If a permanent file length error is detected, 
the file being retrieved is not given to the user (unless the 
user is SYOT) as the data currently residing on the tracks 
specified for the file in error may contain someone else's data. 
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FILE ACCESS 

The permanent file subsystem has a variety of mechanisms whereby 
a user may control the access to his permanent files. These 
mechanisms include the file category (public, private, and 
semi-private) and the file password. The system provides the 
secure entry and suppressing of permanent file passwords so that 
these values do not appear on hard-copy output. More detail on 
the access constraints available for user permanent files is 
found in the NOS Reference Manual, volume 1. 

In addition to the mechanisms that control access to permanent 
files on the basis of ownership (user number), a method exists 
which enables a job step to prevent subsequent access to a file 
it creates. This feature is known as user file privacy and is 
intended especially for use by application programs. When 
selected (turned on), files created by the job step have a 
special ID assigned by routine OBF. Routine 1AJ returns such 
files prior to initiating the next control statement in the job 
stream. For information on the use of this feature, refer to 
the PROTECT macro in the NOS Reference Manual, volume 2. 

SYSTEM FILE ACCESS 

The SYSTEM file may be accessed in a variety of ways such that it 
is impossible to deny all users access to it. Therefore, 
programs and procedure files that are part of the SYSTEM file 
should not have user numbers, passwords, or charging information 
i n them . 
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